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Preface 


This textbook is intended to provide information systems students with the background 
knowledge and skills necessary to begin using the basic facilities of a mainframe 
computer. 


Students are assumed to have successfully completed an introductory course in computer 
system concepts, one or more programming languages, and be PC literate. Students 
might, for example, have previously taken courses in computer organization and 
architecture, operating systems, data management, and data communications. This 
textbook can also used as a prerequisite for courses in advanced topics, such as compiler 
algorithms, or for internships and special studies. 


Others who will benefit from this textbook include data processing professionals who 
have experience with using non-mainframe platforms, or are familiar with some aspects 
of the mainframe but want to become knowledgeable with other facilities and benefits of 
the mainframe environment. 


As we go through this textbook, we suggest that the instructor alternate between text, 
lecture, discussions, and hands-on exercises. The instructor-led discussions and 
hands-on exercises are an integral part of the learning experience, and can include topics 
not covered in this textbook. 


At the end of this textbook, you will know: 


> A general introduction to mainframe concepts, usage, and zSeries architecture 

> A comprehensive overview of z/OS, the most commonly used mainframe operating 
system 

> An understanding of mainframe workloads and an overview of the major middleware 
applications in use on mainframes today 

> The basis for subsequent course work in more advanced, specialized areas of z/OS, 
such as system administration or application programming. 


How this textbook is organized 


This textbook is organized in four parts, as follows: 


> Part 1. “Introduction to z/OS and the mainframe environment” provides an 
overview of the types of workloads commonly processed on the mainframe, such as 
batch jobs and online transactions. This part of the textbook helps students explore 
the user interfaces of z/OS, a widely-used mainframe operating system. Discussion 
topics include TSO/E and ISPF, job control language, UNIX interfaces, and network 
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communications. Special attention is paid to the users of mainframes and to the 
evolving role of mainframes in today’s business world. 


> Part 2. “Applications and development on the mainframe” introduces the tools 
and utilities for developing a simple program to run on the mainframe. This part of 
the textbook guides the student through the process of application design, choosing a 
programming language, and using a runtime environment. 


> Part 3. “Deploying large workloads on the mainframe” examines the major 
categories of workloads processed by the mainframe, such as transaction processing, 
database management, and Web-serving. This part of the textbook includes 
discussions of several popular middleware products, including DB2, CICS, and 
WebSphere. 


> Part 4. “Moving work into production on the mainframe” provides additional 
details to help the student system programmer enable the mainframe for new 
workloads. This part of the textbook includes discussions of system libraries, security, 
starting and stopping the operating system, and the clustering of multiple systems. 
This part also provides an overview of mainframe hardware systems, including 
processors and I/O devices. 


In this textbook, we use simplified examples and focus mainly on basic system functions. 
Hands-on exercises are provided throughout the textbook to help students explore the 
mainframe style of computing. Exercises include entering work into the system, checking 
its status, and examining the output of submitted jobs. 
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redbook@us.ibm.com 
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Instructor Notes 


This textbook is designed to serve as the basis for a one semester course that meets 
regularly for approximately 13 to 15 weeks of lecture and labs. The number of hours per 
week will vary, according to your objectives as the instructor, and the requirements of the 
educational institution. 


To allow adequate time to complete the textbook, we suggest that you devote 
approximately two thirds of the classroom time to lecture, and reserve the remaining time 
for instructor-led discussions and hands-on exercises. 


Alter this timetable as needed to meet your requirements for the course and to permit 
enough time for teaching other mainframe-related topics, if desired. Wherever possible, 
the chapters in this textbook were designed to be self-contained and modular. As a result, 
you can vary the sequence of chapters to suit the requirements of a given syllabus. 


To perform the labs and exercises, you and your students will require the use of a 
computer system running the z/OS operating system and access to the lab-related 
materials. In place of z/OS system, you can substitute an older variant of the operating 
system, such as OS/390 or MVS/ESA. 


Enabling your classroom for z/OS lab exercises 


Throughout this textbook, hands-on labs and exercises are provided to help students learn 
mainframe concepts and facilities. To perform the labs and exercises, your students will 
require the use of a computer running the z/OS operating system and access to the 
supplied labs. 


The tasks for making the class labs available to your students are described in the 
sections that follow. 


Accessing the labs 


How you access the labs depends on whether the classroom z/OS system is real or 
emulated, and whether access to the system is through local or remote means. 


You can use the labs in any of the following settings: 


> z/OS system provided locally by your university. Here, it is recommended that you 
work with the university’s mainframe support staff to copy the class data sets to the 
z/OS system that you plan to use during the course. The data sets are supplied on the 
CD-ROM that accompanies this textbook. 


> Emulated z/OS system on a PC. One such product for emulating z/OS is called 
FLEX-ES, which is offered by Fundamental Software, Incorporated, of Fremont, 
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California. FLEX-ES supports the same instruction set as a real zSeries mainframe 
and runs the same operating systems and applications. For information about 
obtaining a FLEX-ES machine with z/OS and class labs pre-installed, contact the 
IBM Scholars program: 


http: //www.developer.ibm.com/us/en/university/scholars/products/zseries/ 


> z/OS system provided remotely. For example, Marist College, USA, provides 
remote access to a z/OS system, which already includes the class labs. Contact an 
IBM Scholars representative (at the above Web site) to receive system logon access 
and information about the lab materials. 


The sections that follow provides instructions for installing the labs and performing 
additional setup tasks required to enable the classroom system for lab work. Wherever 
possible, we have attempted to minimize the complexity of installing the labs. However, 
it is strongly suggested that you, the instructor, carefully review and test these 
instructions on the classroom system before starting the course. 


Preparing to install the class lab materials 


Before installing the class labs and exercises from the CD-ROM that accompanies this 
textbook, you must create a user catalog and alias for the class, and define an instructor’s 
user ID (the ZPROF user ID) for yourself. It is recommended that you work with the 
system programmer to perform these steps. 


This section describes the sample jobs that you and your system programmer can use to 
perform these tasks, as follows: 


> “Create the user catalog and ZSCHOLAR alias” on page -vii 
> “Define the ZPROF user ID” on page -vii 
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Create the user catalog and ZSCHOLAR alias 
Ask your system programmer to create and run a job like ADDUCAT (Example 0-1) to 
define the user catalog and the ZSCHOLAR alias for the class. 


//ADDUCAT JOB 1,NOTIFY=&SYSUID 

[| [BRRRRRERRRARERER ERE RR RRER ER EKER ER ER ERE EKER ERE REREERERERE | 
x 

//* Locate existing USERCAT to use as MODEL for defining */ 

//* attributes of new USERCAT.ZUSERS 

//* F CATALOG,OPEN system command may help */ 

[| [BRRRRRRRRRRRERER ERE RRR ER ERE RER ER ERE EERE RE RE REREREREREERE | 

{i5l EXEC PGM=IDCAMS 

//SYSPRINT DD SYSOUT=* 

//SYSIN DD * 


DEFINE USERCATALOG ( NAME( USERCAT.ZUSERS ) - 


[| [BRRRRRERRRARERER RRR ER RR ER ERE KER ER ERE ERE REREREREREERERERE | 


//* OPTIONAL - define a Alias for HLQ ZSCHOLAR 
[| [BRRRRRERRRARERER RR EER RR ER ERE KER ER ER ER ERE KER ERE REREERERERE | 
//ALIAS EXEC PGM=IDCAMS 
//SYSPRINT DD SYSOUT=* 
//SYSIN DD * 

DEFINE ALIAS (NAME(ZSCHOLAR) RELATE(USERCAT.ZUSERS) ) 





Figure 0-1 Job to create class a user catalog and the ZSCHOLAR alias 


Define the ZPROF user ID 


Ask your system programmer to create and run a job like ZPROFA (Example 0-1 on 
page -vii) to define the ZPROF user ID for your use during the class. In the sample code, 
the system programmer must modify the CLASS(TSOPROC) PERMIT statements to 
include local system TSO logon procedures (PROCs). 
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//ZPROFA JOB 1,NOTIFY=&SYSUID 
//ALIAS EXEC PGM=IDCAMS 
//SYSPRINT DD SYSOUT=* 
//SYSIN Go * 
DEFINE ALIAS (NAME(ZPROF ) RELATE(USERCAT.ZUSERS) ) 
//ADDID EXEC PGM=IKJEFTO1,REGION=6M 
//SYSPRINT DD SYSOUT=* 
//SYSTSPRT DD SYSOUT=* 
//SYSTERM DD DUMMY 
//SYSTSIN DD * 

MKDIR '/u/zprof' 

AU ZPROF NAME('A. Teacher') PASSWORD (MYZPWD) 
OWNER(SYS1) DFLTGRP(SYS1) UACC(READ) SPECIAL OPERATIONS 
TSO(ACCTNUM(ACCT#) PROC(ISPFPROC) JOBCLASS(A) MSGCLASS (xX) 

HOLDCLASS(X) SYSOUTCLASS(X) SIZE(2048000) MAXSIZE(0)) 
OMVS (HOME (/u/zprof) PROGRAM(/bin/sh) UID(0)) 

PERMIT ACCT# CLASS (ACCTNUM) ID(ZPROF) 

PERMIT ISPFPROC CLASS(TSOPROC) ID(ZPROF) 

PERMIT DBSPROC CLASS(TSOPROC) ID(ZPROF) 

PERMIT JCL CLASS(TSOAUTH) ID(ZPROF) 

PERMIT OPER CLASS(TSOAUTH) ID(ZPROF) 

PERMIT ACCT CLASS(TSOAUTH) ID(ZPROF) 

PERMIT MOUNT CLASS (TSOAUTH) ID(ZPROF) 

PERMIT ‘USERCAT.*? ACCESS(UPDATE) ID(ZPROF) 

AD 'ZPROF.*' OWNER(ZPROF) UACC(READ) GENERIC 

SETROPTS REFRESH RACLIST(TSOPROC) 





Figure 0-2 Job to create class user catalog and ZPROF alias 


Installing the class lab materials 


This section describes the sample jobs that you and your system programmer can use to 
create the classroom environment on z/OS, as follows: 


“Step 1: Upload the CD-ROM file” on page -viii 

“Step 2: Convert the uploaded file to DUMP format” on page -ix 

“Step 3: Create the class data sets” on page -x 

“Step 4: Create the student user IDs and data sets” on page -x 

“Step 5: Optionally create authorizations for database exercises” on page -x 
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Step 1: Upload the CD-ROM file 


Begin by logging on to the system with your ZPROF user ID. To upload the 
ZSCHOLAR.XMIT file from the CDROM to z/OS, you can use FTP or a 3270 emulator 
data transfer function. 


Each method is described here. 
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FTP method: To use FTP to upload the ZSCHOLAR.XMIT file, do the following: 
1. Obtain the z/OS system IP address or DNS entry from your system administrator. 
2. On your workstation, change the directory to the CDROM drive letter 
3. FTP to the z/OS system from the workstation command prompt 
4. Enter your user ID and password. Then, enter these commands: 

ftp> quote site unit=sysallda lrecl=80 blksize=3120 recfm=fb 


ftp> quote site cylinder primary=3 secondary=1 


ftp> bin 


ftp> put zscholar.xmit ‘zprof.zscholar.xmit’ 


ftp> bye 





Figure 0-3 FTP commands to upload from CD-ROM to z/OS system 


3270 emulator method: To upload the ZSCHOLAR.XMIT file through a 3270 emulator 
data transfer, do the following: 


1. Specify the data transfer options: 


— MVS/TSO 
— binary 
— Irecl(80) 
— blksize(3120) 
— recfm(fb) 
— allocation units(cylinder) 
— primary allocation amount(3) 
2. Select the ISPF command shell panel 


3. Send the file to host data set ‘ZPROF.ZSCHOLAR.XMIT’ 


Step 2: Convert the uploaded file to DUMP format 


On the z/OS system, convert the uploaded data set from XMIT format to data set DUMP 
format. To do so, enter the following command: 


TSO RECEIVE INDA(‘ZPROF.ZSCHOLAR.XMIT*) 


When prompted for restore parameters, press Enter. The system creates the 
ZPROF.ZSCHOLAR.DUMP data set. 


Preface ix 


Preface.fm 


x 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm 


Step 3: Create the class data sets 
Use a job like the one shown in Example 0-1 to restore the class data sets using the 


valid disk volume on the target system: 


//S1 EXEC PGM=ADRDSSU, REGION=4M 
//SYSPRINT DD SYSOUT=* 
//1NDD DD DISP=SHR, DSN=ZPROF.ZSCHOLAR. DUMP 
//SYSIN DD * 
RESTORE DATASET(INCLUDE(**)) - 


Example 0-1 Job to restore the class data sets 
The job creates a master copy of ZPROF.ZSCHOLAR.** data sets for the class. 


Create a working copy from the restored data sets for your use. To do so, enter the 
following command: 


Submit ‘ZPROF.ZSCHOLAR. INST.CNTL(ZPROFDS) ’ 


This job copies the ZPROF.ZSCHOLAR.** data sets to ZPROF.** data sets, which you 
can use as the working copies. It is recommended that you keep the original 
ZPROF.ZSCHOLAR.** data sets, as backup copies in case you need them later. 


Step 4: Create the student user IDs and data sets 


Define the student user IDs and create the lab data sets. To define a group of 12 student 
user IDs and lab data sets at one time, edit and run the following job: 


> ZPROF.INST.CNTL(ZCLASS) 
To permit students 13 through 24 to be defined, uncomment lines in the job as needed. 


To define students individually, edit and run the following jobs, once per student. 


> ZPROF.INST.CNTL(ZUSERADD) 
> ZPROF.INST.CNTL(ZUSERDS) 


Also, you might find the ZUSERDS job to be useful for replacing individual student data 
sets. In the job, replace ZPROF.ZSCHOLAR.*.* with the name of the data set to be 
restored. 


Step 5: Optionally create authorizations for database exercises 
As the instructor, you might want to have DBA authority, so that you can verify student 
work on databases and grant authorizations to students. To obtain DBA authority, check 
with your system administrator. 
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The supplied course materials include a file with sample authorizations (SQL statements) 
that you can modify and run from the SPUFI program. See the following data set 
member: 


ZPROF .ZSCHOLAR. INST. CNTL (GRANTS) 


You might find, however, that access to the sample tables is sufficient for the class 
exercises, and that you do not require DBA authority. 


Other instructor tasks 

During the course, it is likely that you will want to back-up student data sets periodically 
(weekly is recommended) to reduce the chances of accidental loss. As a sample, the 
course materials include the DATATAPE job, which you can modify to dump your class 
data sets to tape. 
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Part 1 


Introduction to z/OS and the 
mainframe environment 


Welcome to mainframe computing! 


We begin this book by exploring the mainframe environment and the reasons why 
mainframe computers form the foundation of information technology organizations 
throughout the world. We discuss the types of workloads commonly processed on the 
mainframe, such as batch jobs and online transactions, and the unique manner in which 
this work is processed by the z/OS operating system. Special attention is paid to the 
various users of mainframes and to the evolving role of mainframes in today’s business 
world. 


At the end of this part, you will know: 


> 


vvvy 


Mainframe concepts and usage, and the primary roles and responsibilities of the staff 
in an mainframe organization 

TSO/ISPF, the primary user interface for z/OS 

Major types of workloads performed on the mainframe 

Concepts of UNIX interfaces on z/OS 

Concepts of network communications on z/OS. 
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1 


Introduction to mainframe computing 








Objective: As a technical professional in the world of mainframe computing, 
you need to understand how mainframe computers support your company’s IT 
infrastructure and business goals. You also need to know the job titles of the 
various members of your company’s mainframe support team. 


In this chapter, you will learn: 


> Why most large companies rely on mainframe computers and have done so 
since the 1960s 

> How businesses make use of mainframe processing power, the typical uses 
of mainframes, and how mainframe computing differs from other forms of 
computing 

> Which jobs and responsibilities are related to mainframe computing 

> What other operating systems are available on the mainframe 
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1.1 Mainframes today 


The long-term success of mainframe computers is without precedent in the information 
technology (IT) field. Periodic upheavals in world economies and continuous, often 
wrenching change in the Information Age have claimed many once compelling 
innovations as victims in the relentless march of progress. As emerging technologies leap 
into the public eye, most are, it seems, just as suddenly rendered obsolete by some even 
newer advancement. Yet today, as in every decade since the 1960s, mainframes and the 
mainframe style of computing, dominate the landscape of large-scale business 
computing. 


Why has this one form of computing taken hold so strongly among the world’s largest 
corporations? The mainframe computer began its initial growth spurt in the 1960s. At 
that time, mainframes were the only type of computers, and few businesses could afford 
them. Of the small number sold at the time, each mainframe was uniquely tailored to 
match a customer’s primary (and often only) business application. 


In 1964, however, things changed dramatically when mainframe manufacturers began to 
standardize the hardware and software they offered to customers!. This change signaled 
the start of the age of the general purpose computer. With standardized mainframes to 
run their workloads, customers could, in turn, write business applications without need 
for specialized hardware or software. Moreover, customers were free to upgrade to newer 
and more powerful processors without concern for incompatibility problems with their 
existing applications. The first wave of customer business applications were mostly 
written in COBOL, FORTRAN, or PL/I, and many of these older programs or /egacy 
applications are still in use today. 


In the decades since the 1960s, mainframe computers have steadily grown to achieve 
enormous processing capabilities. Mainframes of today have an unrivaled ability to serve 
end users by the tens of thousands, manage petabytes of data, and reconfigure hardware 
and software resources to match changes in workload--all from a single point of control. 


1.2 Evolving architecture 


1-2 


Starting with the first “Big Iron” machines, which arrived on the scene in the 1960s, each 

new generation of mainframes has added improvements in one or more of the following 
2 

areas: 


' TBM introduced System/360 (or S/360), the first general purpose computing architecture, in 1964. 

? Since the introduction of $/360 in 1964, IBM has significantly extended the platform roughly every ten years: 
System/370 in 1970, System/370 Extended Architecture (370-XA) in 1983, Enterprise Systems 
Architecture/390 (ESA/390) in 1990, and z/Architecture in 2000. For more information about earlier 
mainframe hardware systems, see Appendix F, “A Little Bit of IBM Mainframe History”. 
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“I predict that 
the last 
mainframe will 
be unplugged 
on March 15, 
1996.” 


--Stewart 
Alsop, 
Infoworld, 
March 1991 


More and faster processors 

More physical memory and greater memory addressing capability 

Dynamic capabilities for upgrading both hardware and software 

More sophisticated automated hardware error checking and recovery 

Enhanced devices for input/output (I/O) and more and faster paths (channels) 

between I/O devices and processors 

Sophisticated I/O attachments, such as LAN adapters with extensive inboard 

processing 

> Increased ability to divide the resources of one machine into multiple, logically 
independent and isolated systems, each running its own operating system 

> Enhanced clustering technologies, such as Parallel Sysplex, and the ability to share 

data among multiple systems. 


vvvvy 


Vv 


Despite the continual change, mainframes remain the most stable, secure and compatible 
of all computing platforms. The latest models can handle the most advanced and 
demanding customer workloads, yet continue to run many applications that were written 
in the 1970s or earlier. 


How is it possible that a technology can change so much, yet remain so stable? By 
evolving to meet new challenges; for example, in the early 1990s, the client/server model 
of computing, with its distributed nodes of less powerful computers, emerged to 
challenge the dominance of mainframes. Industry pundits predicted a swift end for the 
mainframe and called it a “dinosaur.” In response, mainframe designers did what they 
have always done when confronted with changing times and changing user requirements: 
They designed new mainframe computers to meet the demand. With a tip of the hat to the 
dinosaur naysayers, IBM, a leading manufacturer of mainframes, even code-named its 
newest, most powerful mainframe 7-Rex. 


With expanded functions and added tiers of data processing capabilities such as 
Web-serving, autonomics, disaster recovery and grid computing, the mainframe is once 
again poised to ride the next wave of growth in the IT industry. Mainframe manufacturers 
such as IBM are once again reporting annual sales growth in double digits. 


And the evolution continues. While the mainframe has retained its traditional, central 
role in the IT organization, that role is now defined to include being the primary hub in 
the largest distributed networks. In fact, the Internet itself is based largely on many 
interconnected mainframes serving as major hubs and routers. 


As the image of the mainframe continues to change, you might ask: Is the mainframe a 
self-contained computing environment, or one part of the puzzle in distributed 
computing? The answer is that the mainframe is both: A self-contained processing center, 
powerful enough to process the largest workloads in one secure “footprint,” but one that 
is also just as effective when implemented as the primary server in a corporation’s 
distributed server farm. In effect, the mainframe is the ultimate server in the client/server 
model of computing. 
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1.3 Mainframes in our midst 


Despite the prevalence of mainframes in the business world, these machines are largely 
invisible to the general public, the academic community, and indeed many experienced 
IT professionals. Instead, other forms of computing predominate, at least in terms of 
visibility and public awareness. That this is so is perhaps not surprising. After all, who 
among us needs direct access to a mainframe? And, if we did, where would we find one 
to access? 


Most of us with some PC literacy (and sufficient funds) can purchase a notebook 
computer and quickly put it to good use--running software, browsing Web sites, and 
perhaps even writing papers for college professors to grade. With somewhat greater 
effort and technical prowess, we can delve more deeply into the various facilities of a 
typical Intel-based workstation and learn its capabilities through direct, hands-on 
experience--with or without help from any of a multitude of readily available information 
sources in print or on the Web. 


Mainframes, however, tend to be hidden from the public eye. They do their jobs 
dependably--indeed, with almost supernatural reliability--and are highly resistant to most 
forms of insidious abuse that afflict PCs, such as e-mail-borne viruses, Trojan Horses, 
and the like. By performing stably, quietly, and with negligible downtime, mainframes 
are perhaps victims of their own success. 


Furthermore, in a real world IT setting, mainframes tend to be hidden by lots of other 
hardware: External storage devices, hardware network routers, channel controllers, 
automated tape library “robots,” and so on. The latest mainframes are no larger than 
many of these devices and generally do not stand out from the crowd of peripheral 
devices. 


So, how can we explore a mainframe’s capabilities in the real world? How can we learn 
to interact with a mainframe computer, learn its capabilities, and understand its 
importance to the business world? Major corporations are eager to hire new mainframe 
professionals, we hear, but there’s a catch: A little previous experience would help. 


Would we even know a mainframe if we saw one, given that these machines have in fact 
evolved to flourish in the jungles of the twenty-first century IT organization? What we 
need is an experienced guide to lead us on a dinosaur safari, which is where this textbook 
comes in! 


1.4 What is a mainframe? 


First, let’s tackle the terminology. Today, computer manufacturers don’t always use the 
term mainframe to refer to mainframes. Instead, most have taken to calling any 
commercial-use computer--large or small--a server, with the mainframe simply being the 
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largest type of server in use today. IBM, for example, now refers to its mainframes as 
zSeries servers. 


Servers are proliferating. A business might have a collection of transaction servers, 
database servers, e-mail servers, Web servers, and so on. Larger collections of servers are 
sometimes called server farms (in fact, some data centers cover areas measured in acres). 
The hardware required to perform a server function can range from little more than a 
cluster of rack-mounted personal computers to the most powerful mainframes 
manufactured today. 


A mainframe is the central data repository or Aub in a corporation’s data processing 
center, linked to users through less powerful devices such as workstations or terminals. 
The presence of a mainframe often implies a centralized form of computing, rather than a 
distributed form of computing. Having data centralized in a single mainframe repository 
saves customers from having to manage updates to more than one copy of their business 
data, thus increasing the likelihood that the data is current. 


This distinction, however, is rapidly blurring as smaller machines continue to gain in 
processing power, and mainframes become ever more flexible and multi-purpose. Market 
pressures require that today’s businesses continually reevaluate their information 
technology (IT) infrastructures to find ways of better supporting a changing marketplace. 
As aresult, mainframes are now frequently used in combination with networks of smaller 
servers in a multitude of configurations. Also, the ability to dynamically reconfigure a 
mainframe’s hardware and software resources (such as processors, memory, and device 
connections) while applications continue running further underscores the flexible, 
evolving nature of the modern mainframe. 


While mainframe hardware has become harder to pigeon-hole, so, too, have the operating 
systems that run on mainframes. Many years ago, in fact, the terms defined each other: A 
mainframe was any hardware system that ran a major IBM operating system. This 
meaning has been blurred in recent years because these operating systems can be run on 
very small systems. 


To refer to a general computer architecture (hardware and software), IT professionals 
often use the term platform. For example, a zSeries machine and its operating system 
(and their predecessors*) is considered a platform. UNIX on a RISC machine is 
considered a platform, somewhat independent of exactly which RISC machine is 
involved. Personal computers can be seen as several platforms, depending on which 
operating system is being used. 


3 The name was also traditionally applied to large computer systems produced by other vendors. 

4 TBM System/390 (S/390) refers to a specific series of machines, and these have been superseded by the 
zSeries. Nevertheless, many S/390 systems are still in use. Therefore, keep in mind that although we discuss the 
zSeries systems in this course, almost everything discussed also applies to S/390 machines as well. The most 
obvious exception is the use of 64-bit addressing, which is used only with zSeries machines. 
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So, let’s return to our question now: “What is a mainframe?” Today, the term mainframe 
can be better used to describe a style of operation, applications and operating system 
facilities. To start with a working definition, “a mainframe is what businesses use to host 
the commercial databases, transaction servers, and applications that require a greater 
degree of security and availability than is commonly found on smaller-scale machines.” 


Early mainframe systems were housed in 
enormous, room-filling metal boxes or 
frames, and this is probably how the term 
mainframe originated. The mainframe 
required large amounts of electrical power 
and air-conditioning, and the room was 
occupied mostly by I/O devices. Also, a 
typical installation had several 
mainframes installed with most of the I/O 
devices connected to all of the 
mainframes. During their largest period in terms of physical size, a typical mainframe 
occupied 2000-10,000 square feet (200-1,000 square meters), with some installations 
being much larger than this. 





Starting around 1990, mainframe processors and most of the 
I/O devices became physically smaller, while their 
functionality and capacity continued to grow. Mainframe 
systems today are much smaller than earlier systems--about the 
size of a large refrigerator. 


Further, it is now possible in some cases to run a mainframe 
operating system on a PC that emulates a zSeries processor. 
Such emulators are useful for developing and testing business 
applications before moving them to a mainframe production 
system. 





Clearly, the term mainframe has expanded beyond merely describing the physical 
characteristics of a system. Instead, the word typically applies to some combination of 
the following attributes: 


> Compatibility with mainframe operating systems, applications, and data. 
> Centralized control of resources. 


> Hardware and operating systems that can share access to disk drives with other 
systems, with automatic locking and protection against destructive simultaneous use 
of disk data. 


> A style of operation, often involving dedicated operations staff who use detailed 
operations procedure books and highly organized procedures for backups, recovery, 
training, and disaster recovery at an alternate site. 
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> Hardware and operating systems that routinely work with hundreds or thousands of 
simultaneous I/O operations. 


> Clustering technologies that allow the customer to operate multiple copies of the 
operating system as a single system. This configuration, known as Parallel Sysplex, is 
analogous in concept to a UNIX cluster, but allows for systems to be added or 
subtracted as needed while applications continue to run. This flexibility allows 
mainframe customers to introduce new applications, or discontinue using existing 
applications, in response to changes in business activity. 


> Additional data and resource sharing capabilities. In a Parallel Sysplex, for example, 
it is possible for users across multiple systems to access the same databases 
concurrently, with database access controlled at the record level. 


1.5 Who uses mainframe computers? 


So, who uses mainframes? Just about everyone has used a mainframe computer at one 
point or another. If you have ever used an automated teller machine (ATM) to interact 
with your bank account, for example, you’ve used a mainframe. 


Today, mainframe computers play a central role in the daily operations of most of the 
world’s largest corporations, such as Fortune 1000 companies. While other forms of 
computing are used extensively in business in various capacities, the mainframe occupies 
a coveted place in today’s e-business environment. In banking, finance, health care, 
insurance, utilities, government, and a multitude of other public and private enterprises, 
the mainframe computer continues to be the foundation of modern business. 


In fact, until the mid-1990s, mainframes provided the only acceptable way of handling 
the data processing requirements of a large business. These requirements were then (and 
are often now) based on large and complex batch jobs, such as payroll and general ledger 
processing. 


The mainframe owes much of its popularity and longevity to its inherent reliability and 
stability, a result of careful and steady technological advances since the introduction of 
System/360 in 1964. No other computer architecture in existence can claim as much 
continuous, evolutionary improvement, while maintaining compatibility with previous 
releases. 


Because of these design strengths, the mainframe is often used by IT organizations to 
host the most important, mission-critical applications. These applications typically 
include customer order processing, financial transactions, production and inventory 
control, payroll, as well as many other types of work. 


A common impression of a mainframe user interface is the 80x24 character “green 
screen” terminal, named for the old CRT-based computer terminals from years ago that 
glowed green. However, current mainframe interfaces can look much the same as those 
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for personal computers or UNIX systems. When a business application is accessed 
through a Web browser, there is often a mainframe computer providing crucial function 
“behind the scenes.” 


Many of today’s busiest Web sites store their production databases on a mainframe host. 
Mainframe hardware and software are ideal for Web transactions because they are 
designed to allow huge numbers of users and applications to rapidly and simultaneously 
access the same data without interfering with each other. This security, scalability, and 
reliability is critical to the efficient and secure operation of contemporary information 
processing. 


Corporations use mainframes for applications that depend on scaleability and reliability. 
For example, a banking institution might use a mainframe to host the database of its 
customer accounts, for which transactions can be submitted from any of thousands of 
ATM locations worldwide. 


Businesses today rely on the mainframe to: 


> Perform large-scale transaction processing (thousands of transactions per second) 

> Support thousands of users and application programs concurrently accessing many 
resources 

> Manage terabytes of information in databases 

> Handle large-bandwidth communications 


The roads of the information superhighway often lead to a mainframe. 


1.6 Factors contributing to mainframe use 


The reasons for mainframe use are many, but most generally fall into one or more of the 
following categories: 


Reliability, availability, serviceability 
Security 

Scalabilty 

Continuing compatibility 

Evolving architecture 


vvvvy 


Let’s look at each of these categories in more detail now. 


1.6.1 Reliability, availability, and serviceability 


Reliability, availability, and serviceability (often grouped together as “RAS”) have 
always been important in data processing. When we say that a particular computer 
system “exhibits RAS characteristics,” we mean that its design places a high priority on 
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the system remaining in production at all times. Ideally, RAS is a central design feature 
of all aspects of a computer system, including the applications. 


RAS has become accepted as a collective term for many qualities of hardware and 
software that are prized by users of mainframes. The terms are defined as follows: 


Reliability Involves the use of high-quality components, but also involves 
extensive self-checking and self-recovery by hardware components. 
Software reliability involves extensive testing and quick updates for 
detected problems. 


Availability Is the ability to recover from a failed component without impacting the 
rest of the running system. This applies to hardware recovery (by 
automatically replacing failed elements with spares) and software 
recovery (through layers of error recovery provided by the operating 
system). 


Serviceability Allows for the replacement of elements (hardware and software) while 
impacting as little of the operational system as possible. It also implies 
well-defined units of replacement, again either hardware or software. 


A computer system is available when its applications are available. An available system 
is one that is reliable, that is, it rarely requires downtime for upgrades or repairs. And, if 
the system is brought down by an error condition, it must be serviceable -- easy to fix -- 
within a relatively short period of time. 


Along with the hardware, mainframe operating systems exhibit RAS through such 
features as storage protection and a controlled maintenance process. These features allow 
a mainframe to run for months and even years before requiring an unscheduled outage or 
upgrade. 


Beyond RAS, a state-of-the-art mainframe system might be said to provide high 
availability and fault tolerance. To achieve these objectives, a mainframe architecture 
can employ redundant components in critical paths to ensure a consistent, highly 
available environment for business applications, in the event that a system component 
fails. Such an approach allows the system designer to minimize the risk of having a 
single point of failure undermine the overall RAS of a computer system. 


1.6.2 Security 


One of a firm’s most valuable resources is its data: Customer lists, accounting data, 
employee information, and so on. This critical data needs to be securely managed and 
controlled, and, simultaneously, made available to those users authorized to see it. 
Mainframe computers have extensive capabilities to simultaneously share, but still 
protect, the firm’s data among multiple users. 
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In an IT environment, security is defined as the protection of data against unauthorized 
access, transfer, modification, or destruction, whether accidental or intentional. To 
protect data and to maintain the resources necessary to meet the security objectives, 
customers typically add a sophisticated security manager product to their mainframe 
operating system. The customer’s security administrator often bears the overall 
responsibility for using the available technology to transform the company’s security 
policy into a usable plan. 


A secure computer system prevents users from accessing or changing any objects on the 
system, including user data, except through system-provided interfaces that enforce 
authority rules. Mainframe computers can provide a very secure system for processing 
large numbers of heterogeneous applications that access critical data. In this textbook, we 
discuss one example of a mainframe security system in Appendix 18, “Security on 
z/OS”. 


1.6.3 Scalability 


It has been said that the only constant is change. Nowhere is that statement truer than in 
the information technology industry. In business, positive results can often trigger a 
growth in IT infrastructure to cope with increased demand. The degree to which the IT 
organization can add capacity without disruption to normal business processes or without 
incurring excessive overhead (nonproductive processing) is largely determined by the 
scalability of the particular computing platform. 


By scalability we mean the ability of the hardware, software, or a distributed system to 
continue to function well as it is changed in size or volume; for example, the ability to 
retain performance levels when adding processors, memory, and storage. A scalable 
system can efficiently adapt to work, with larger or smaller networks performing tasks of 
varying complexity. 


zSeries mainframes exhibit scalability characteristics in both hardware and software, 
with the ability to run multiple copies of the operating system software as a single entity 
called a system complex or sysplex. We further explore mainframe clustering technology 
and its uses in Chapter 23, “Parallel Sysplex” . 


1.6.4 Continuing compatibility 
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Mainframe customers tend to have a very large financial investment in their applications 
and data. Some applications have been developed and refined over decades. Some 
applications were written many years ago, while others may have been written 
“yesterday.” 


The need to support applications of varying ages imposes a strict compatibility demand 
on mainframe hardware and software, which have been upgraded many times since the 
first System/360 mainframe computer was shipped in 1964. Applications must continue 
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to work properly. Thus, much of the design work for new hardware and system software 
revolves around this compatibility requirement. 


The overriding need for compatibility is also the primary reason why many aspects of the 
system work as they do, for example, the syntax restrictions of the job control language 
(JCL) used to control batch jobs. Any new design enhancements made to JCL must 
preserve compatibility with older jobs so that they can continue to run without requiring 
modifications. The desire and need for continuing compatibility is one of the defining 
characteristics of mainframe computing. 


Absolute compatibility across decades of changes and enhancements is not possible, of 
course, but the designers of mainframe hardware and software make it a top priority. 
When an incompatibility is unavoidable, the designers typically warn users at least a 
year in advance that software changes might be needed. 


1.7 Typical mainframe workloads 


Most mainframe workloads fall into either of two categories: batch processing and online 
transactional processing, including Web-based applications (Figure 1-1). 


Application Program 


Process data to 
e Batch Job perform a 
particular task 


Output Data 


Application Program 


Access shared 
data on behalf of 
online user 


e Online Transaction 





Figure 1-1 Typical mainframe workloads 


These workloads are discussed in several chapters in this textbook; the following sections 
provide an overview. 
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1.7.1 Batch processing 
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One key advantage that mainframe systems have is the ability to process terabytes of data 
from high-speed storage devices and produce valuable output. For example, mainframe 
systems make it possible for banks and other financial institutions to produce 
end-of-quarter processing when such reporting is necessary to customers (such as 
quarterly stock statements or pension statements) or to the government (financial results). 
With mainframe systems, retail stores can generate and consolidate nightly sales reports 
for review by regional sales managers. 


The applications that produce these statements are batch applications--they are processed 
on the mainframe without user interaction. A batch job is submitted on the computer, 
reads and processes data in bulk, and produces output, such as customer billing 
statements. 


While batch processing is possible on distributed systems, it is not as commonplace as on 
mainframes because distributed systems often lack: 


> Sufficient data storage 
> Available processor capacity or cycles 
> Sysplex-wide management of system resources. 


Mainframe operating systems are usually equipped with sophisticated job scheduling 
software that allows data center staff to submit, manage, and track the execution and 
output of these batch jobs>. 


Batch processes have the following characteristics: 


> Large amounts of input data are processed, stored records accessed, and a large 
volume of output is produced. 


> Interactive response time is usually not the primary requirement, and the jobs can 
take several minutes to complete. However, batch jobs often must complete within a 
“batch window,” a period of less intensive online activity prescribed by a service 
level agreement. 


> Information is generated about large numbers of users. 


> A scheduled batch process consists of the execution of hundreds or thousands of jobs 
in a pre-established sequence. The process is managed by a specific area in the IT 
organization (the operations staff). 


> In the early days of the mainframe, punched cards were often used to enter jobs into the system 
for execution. “Keypunch operators” used card punches to enter data, and decks of cards (or 
batches) were produced. These were fed into card readers, which read the jobs and data into the 
system. As you can imagine, this process was often cumbersome and error-prone. Nowadays, it’s 
possible to FTP the equivalent of punched card data to the mainframe in a PC text file. We discuss 
the various ways of introducing work into the mainframe in Appendix 5, “Batch processing, JCL, 
and Job Management with JES”. 
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During this type of processing, many reports are generated. For example, consolidated 
information such as profitability of investment funds is provided. Scheduled database 
and data set backups are another good example. 


Figure 1-2 shows a number of batch jobs running in a typical mainframe environment. 
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Figure 1-2 Typical batch use 


In Figure 1-2, consider the following elements at work in the scheduled batch process: 


1. At night, many batch jobs executing programs and utilities are processed. These jobs 
consolidate the results of the online transactions executed during the day. 


2. The batch jobs generate reports of business statistics. 


3. Backups of critical files and databases are made before and after the batch window. 
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4. Reports with business statistics are sent to a specific area for analysis during the 
following day. 


Reports with exceptions are sent to the branch offices. 
Monthly account balance reports are generated and sent to all bank customers. 
Reports with processing summary are sent to the partner credit card company. 


A credit card transaction report is received from the partner company. 


a ed 


In the production control department, the operations area is monitoring the messages 
on the system console and the execution of the jobs. 


10. Jobs and transactions are reading or updating the database (the same database used by 
online transactions) and many files are written to tape. 


1.7.2 Online transactional processing 
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Mainframes serve a vast number of online transaction processing (OLTP) systems. 
These are often mission-critical applications that businesses depend on for their core 
functions. Some industry uses of online systems: 


> Banks — ATMs, teller systems for customer service 
> Insurance — Agent systems for policy management and claims processing 

> Travel and transport — Airline reservation systems 

> Manufacturing — Inventory control, production scheduling 

> Government — Tax processing, license issuance and management. 

How might someone in one of these industries interact with their mainframe system? 
Many factors influence the design of a company’s transaction processing workload, 
including: 


> Number of users interacting with the system at any one time 

> Number of transactions per second (TPS) 

> Availability requirements of the application (for example, must the application be 
available 24 hours a day, seven days a week, or can it be brought down briefly one 
night each week?) 


Based on these factors, user interactions vary from installation to installation. With 
applications now being designed, many installations are reworking their existing 
mainframe applications to include Web browser-based interfaces for users. This work 
sometimes requires new application development, but can often be done with vendor 
software purchased to “re-face” the application. Here, the end user often does not realize 
that there is a mainframe behind the scenes. In this textbook, there is no need to describe 
the process of interacting with the mainframe through a Web browser, as it is exactly the 
same as any interaction a user would have through the Web. The only difference is the 
machine at the other end! 


Online transactions are familiar to many people. Examples include: 
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> 
> 
> 


ATM machine transactions such as deposits, withdrawals, inquiries, and transfers 
Supermarket payments with debit or credit cards 
Purchase of merchandise over the Internet. 


Online transactions usually have the following characteristics: 


> 


> 
> 
> 


Small amount of input data, few stored records accessed and processed, and small 
amount of data as output. 

Rapid response time, usually less than one second, during the mainframe portion of 
the transaction (network delay can add to the time for the transaction to complete). 
Large numbers of users involved in large numbers of transactions. 

Round-the-clock availability of the transactional interface to the user. 

Assurance of security for transactions and user data. 


In a bank branch office, for example, customers use online services when checking 
account balance or making an investment. 


Figure 1-3 shows a series of common online transactions using a mainframe. 
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Figure 1-3 Typical online use 
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1. A customer uses an ATM, which presents a user-friendly interface for various 
functions: Withdrawal, query account balance, deposit, transfer, or cash advance from 
a credit card account. 


2. Elsewhere in the same private network, a bank employee in a branch office performs 
operations such as consulting, fund applications, and money ordering. 


3. At the bank’s central office, business analysts tune transactions for improved 
performance. Other staff use specialized online systems for office automation to 
perform customer relationship management, budget planning, and stock control. 


4. All requests are received in a TCP/IP network and directed to the mainframe 
computer for processing. 


5. Programs running on the mainframe computer perform updates and inquires to the 
database management system (for example, DB2). 


6. Specialized hardware (a disk storage controller) stores the database files. 


1.8 Roles in the mainframe world 
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Mainframe systems are designed to be used by large numbers of people. Most of those 
who interact with mainframes are end users — the people who use the applications that are 
hosted on the system. However, because of the large number of end users, applications 
running on the system, and the sophistication and complexity of the system software that 
supports the users and applications, a variety of roles are needed to support and operate 
the system. 
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Figure 1-4 Roles in the mainframe world 


For example, application programmers are needed to create and maintain application 
programs. Systems programmers are responsible for installing and maintaining the 
underlying system software and operating systems that run on the mainframe. System 
administrators maintain various types of databases on the system. System operators 
monitor and control the system and look for unusual conditions during daily operations. 


In the distributed systems world, many of the same roles are needed as in the mainframe 
environment. However, the job responsibilities are often not as well-defined. Since the 
1960s, mainframe roles have evolved and expanded to provide an environment in which 
the system software and applications can function smoothly and effectively and 
efficiently serve huge numbers of users. While it may seem that the size of the mainframe 
support staff is large and unwieldy, the numbers become comparatively small when one 
considers the number of users supported, the number of transactions run, and the high 
business value of the work performed on the mainframe. 


This section concentrates on the systems programmer and application programmer roles 
in the mainframe environment. However, there are many other important roles involved 
in the “care and feeding” of the mainframe, and this chapter touches on some of these to 
give a better idea of what’s going on behind the scenes. 
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In mainframe computing, roles have many different titles; this textbook uses the 
following: 


Systems programmers 

System administrators 

Application designers and programmers 
System operators 

Production control analysts. 


vvvvy 


Mainframe activities, such as the following, often require cooperation between the 
various roles: 


> Installing and configuring system software 

> Designing and coding new applications to run on the mainframe 

> Introduction and management of new workloads on the system, such as batch jobs 
and online transaction processing 

> Operation and maintenance of the mainframe software and hardware. 


In the following sections, we describe each role in more detail. 


1.8.1 The systems programmer 
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In a mainframe IT organization, the systems programmer plays a central role. The 
systems programmer installs, customizes, and maintains the operating system, and also 
installs or upgrades products that run on the system. The systems programmer might be 
presented with the latest version of the operating system to upgrade the existing systems. 
Or, the installation might be as simple as upgrading a single program, such as a sort. 


In any case, the systems programmer must perform tasks like the following: 


Planning system upgrades and changes in configuration 

Training system operators and application programmers 

Automating operations 

Unloading tapes/installation media 

Running installation jobs and scripts 

Performing installation-specific customization tasks 

Integration-testing the new products with existing applications and user procedures 
System-wide performance tuning to meet required levels of service. 


vvvvvvvy 


If this seems like a lot, consider that the systems programmer also oversees changes to 
the hardware configuration, which usually involves capacity planning (based on 
projections of future business growth), and defining new hardware resources to the 
operating system, such as I/O channels and storage devices. When new hardware storage 
devices, tape drives, networking hardware, or other devices are introduced to the data 
center, the systems programmer works with the operations team to ensure that the devices 
are defined appropriately to the operating systems and to the mainframe hardware. In the 
past, this work often required system outages and other disruptive actions, but new 
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mainframe hardware and operating systems allow the configuration to be updated with 
little or no impact to running systems. 


The systems programmer must be skilled at debugging problems with system software. 
These problems are often manifested by system dumps that have been produced by the 
software products or in user jobs or transactions. Armed with dumps and specialized 
debugging tools, the systems programmer can determine where the components have 
failed. When the error has occurred in a software product, the systems programmer must 
work directly with the software vendor’s support representatives to discover whether the 
problem cause is known and whether a patch is available. 


Systems programmers are needed to install and maintain the database management 
systems and the online transaction processing systems, as well as the operating systems. 
Major mainframe products such as DB2, CICS, and IMS can be as complex, if not more 
so, than the operating system itself. There are a wide variety of system configuration 
options to be maintained, in addition to the daily monitoring and debugging of the 
system. And, on the database side, the database administrator (DBA) is also present to 
ensure the integrity and smooth operation of the data that is stored in the database 
management systems. These roles are not necessarily unique to the mainframe 
environment, but they are key to its smooth operation nonetheless. 


1.8.2 The system administrator 


The distinction between “systems programmer” and “system administrator” varies 
widely among mainframe sites. In many smaller IT organizations, where one person 
might be called upon to perform several roles, the terms are used interchangeably. 


In larger IT organizations with multiple departments, the job responsibilities tend to be 
more clearly separated. System administrators perform more of the day-to-day tasks 
related to maintaining the critical business data that resides on the mainframe, while the 
systems programmer focuses on maintaining the system itself. One reason for the 
separation of duties is to comply with auditing procedures, which often require that no 
one person in the IT organization be allowed to have unlimited access to sensitive data or 
resources. Examples of system administrators include database administrators and 
security administrators. 


While systems programmer expertise lies mainly in the mainframe hardware and 
software areas, system administrators are more likely to have experience using 
alternative platforms, such as UNIX, Linux or Microsoft Windows. The system 
administrator will have some knowledge of command line usage (as part of UNIX 
training), but is accustomed to using graphical user interfaces (GUIs) and automation to 
perform tasks such as security management and definition of new users to the system. 
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In larger IT organizations, the system administrator maintains the system software 
environment for business purposes, including the day-to-day “care and feeding” of 
systems to keep them running smoothly. 


Other examples of common system administrator tasks can include: 


Installing software 

Adding, altering, updating users, and updating resource access lists 
Managing storage devices and printers 

Managing networks and connectivity 

Monitoring system performance. 


vvvvy 


In matters of problem determination, the system administrator generally relies on the 
software vendor support center personnel to diagnose problems, read dumps, and identify 
corrections for cases in which these tasks aren’t performed by the systems programmer. 


1.8.3 The application programmer 
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The application programmer builds, tests, and delivers the applications that run on the 
mainframe for the company’s end users and customers. The programmer gathers 
requirements from business analysts and end users and constructs application programs 
through a variety of tools. The process includes many iterations of code changes and 
compiles, application builds, and unit testing. 


During the application development process, the programmer must interact with other 
roles in the enterprise. In addition to gathering input from the user community, the 
programmer often works on a team of other programmers who are building code for 
related application program modules. When completed, each module is passed through a 
testing process that can include function, integration, and system-wide tests. Following 
the tests, the application programs must be acceptance tested by the user community to 
determine whether the code actually satisfies the original user requirement. 


Producing well-tested code requires the use of tools on the mainframe. The primary tool 
for the programmer is the system editor. When developing traditional, procedural 
programs in languages such as COBOL and PL/I, the programmer often logs on to the 
mainframe and uses the system editor to modify the code, compile it, and run it. The 
programmer also uses a common repository to store code that is under development, and 
can update and save code in a change-controlled process that ensures programmers do 
not interfere with each others’ work. 


When the source code changes are complete, the programmer conducts “unit tests” of the 
functionality of the program. The programmer uses job monitoring and viewing tools to 
track the running programs, view the output, and make appropriate corrections to source 
code or other objects. Sometimes, a program will create a “dump” of memory when a 
failure occurs. The programmer can also use tools to interrogate the dump output and to 
trace through executing code to identify the failure points. 
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Some mainframe application programmers have now switched to the use of Interactive 
Development Environment (IDE) tools to accelerate the edit/compile/test process. IDEs 
such as the WebSphere Studio Enterprise Developer allow application programmers to 
edit, test, and debug source code on a workstation instead of directly on the mainframe 
system. The use of the IDE is particularly useful for building “hybrid” applications that 
employ host-based programs or transactional systems, but also contain a Web 
browser-like user interface. After the components are developed and tested, the 
application programmer packages them into the appropriate deployment format and 
passes them to the team that coordinates production code deployments. 


In addition to creating new application code, the programmer is responsible for 
maintaining and enhancing the company’s existing mainframe applications. In fact, this 
is frequently the primary job for many application programmers on the mainframe today. 
While many mainframe installations still create new programs with COBOL or PL/I, 
languages such as Java have become popular for building new applications on the 
mainframe, just as on distributed platforms. 


Widespread development of mainframe programs written in high-level languages such as 
COBOL and PL/I continues at a brisk pace, despite rumors to the contrary. Many 
thousands of programs are in production on mainframe systems around the world, and 
these programs are critical to the day-to-day business of the corporations that use them. 
COBOL and other high-level language programmers are needed to maintain existing 
code and make updates and modifications to existing programs. Also, many corporations 
continue to build new application logic in COBOL and other traditional languages, and 
IBM continues to enhance the high-level language compilers to include new functions 
and features that allow those languages to continue to exploit newer technologies and 
data formats. 


1.8.4 The system operator 


The system operator monitors and controls the operation of the mainframe hardware and 
software. The operator starts and stops system tasks, monitors the system consoles for 
unusual conditions, and works with the systems programming and production control 
staff to ensure the health and normal operation of the systems. 


Console messages are often cryptic and can be so voluminous that the operator has a 
difficult time in determining when a situation is really a problem. In recent years, 
however, tools to reduce the volume of messages and automate message responses to 
routine situations have made it easier for operators to concentrate on unusual events that 
might require human intervention. 


The operator is also responsible for starting and stopping the major subsystems, such as 
transaction processing systems, database systems, and the operating system itself. These 
restarts are not nearly as commonplace as they once were, as the availability of the 
mainframe has improved dramatically over the years. But the operator is still required to 
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perform an orderly shutdown and startup of the system and its workloads when and if 
required. 


In case of a failure or an unusual situation, the operator communicates with systems 
programmers, who assist the operator in determining the proper course of action, and 
with the production control analyst, who works with the operator to ensure that 
production workloads are completing properly. 


1.8.5 The production control analyst 


The production control analyst is responsible for ensuring that batch workloads run to 
completion--without error or delay. Many mainframe installations run interactive 
workloads for online users, followed by batch updates that run after the prime shift when 
the online systems are not running. While this execution model is still common, 
world-wide operations at many companies--with live, Internet-based access to 
production data--are finding the “daytime online/night time batch” model to be obsolete. 
Batch workloads continue to be a part of information processing, however, and skilled 
production control analysts play a key role. 


A common complaint about mainframe systems is that they are inflexible and hard to 
work with, specifically in terms of implementing changes. The production control 
analyst often bears the brunt of this type of complaint because this person is responsible 
for maintaining rigorous change control procedures. Using fairly structured rules and 
procedures to control changes that are introduced to the system and to the production 
run-time libraries helps the production control analyst prevent outages. In fact, one 
reason that mainframes have attained a strong reputation for high levels of availability 
and performance is that there are controls on change and it is difficult to introduce change 
without proper procedures. 


1.8.6 Vendor support for the mainframe 
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A number of vendor roles are commonplace in the mainframe shop. Because most 
mainframe computers are sold by IBM and the operating systems and primary online 
systems are also provided by IBM, most vendor contacts are IBM employees. However, 
there are also independent software vendor (ISV) products that are used in the IBM 
mainframe environment, and many customers also use original equipment manufacturer 
(OEM) hardware, such as disk and tape storage devices. 


Following are typical vendor roles: 


> Hardware support or Customer Engineer — Hardware vendors usually provide on-site 
support for hardware devices. The IBM hardware maintenance person is often 
referred to as the Customer Engineer (CE). The CE provides installation and repair 
service for the mainframe hardware and peripherals. The CE usually works directly 
with the operations teams when hardware fails or new hardware is being installed. 
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> Software support — A number of vendor roles exist to support software products on 
the mainframe®. IBM provides a centralized Support Center that gives entitled and/or 
extra-charge support for software defects or usage assistance. There are also 
information technology specialists and architects who can be engaged to provide 
additional pre- and post-sales support for software products, depending upon the size 
of the customer and the particular customer situation. 


> “Sales” support — To larger mainframe customers, IBM and other vendors provide 

face-to-face sales support. The sales representatives usually specialize in various 
types of hardware or software product families and will call on the particular part of 
the customer organization that influences the product purchases. In larger mainframe 
accounts, IBM frequently assigns a “client representative”. The client representative 
usually works exclusively with one or two customers in the same industry and is very 
attuned to the business issues in that particular customer or industry sector. The client 
representative also acts as the general “single point of contact’ between the customer 
and the many different roles and organizations within IBM. 


1.9 z/OS and other mainframe operating systems 


1.9.1 2/VM 


Much of this textbook is concerned with teaching you the fundamentals of z/OS, which is 
IBM’s foremost mainframe operating system. We begin discussing z/OS concepts in 
Chapter 2, “z/OS overview” . It is useful for mainframe students, however, to have a 
working knowledge of other operating systems available for mainframes. One reason is 
that a given mainframe computer might run multiple operating systems. For example, the 
use of z/OS, z/VM, and Linux on the same mainframe is common. 


Mainframe operating systems are sophisticated products with substantially different 
characteristics and purposes, and each could justify a separate book for a detailed 
introduction. Besides z/OS, four other operating systems dominate mainframe usage: 
z/VM, VSE, Linux, and TPF. 


This section briefly introduces each of these operating systems. For more information, 
refer to Appendix E, “Other mainframe operating systems”. 


z/Virtual Machine (z/VM) has two basic components: A control program (CP) and a 
single-user operating system, CMS. 


© This textbook does not examine the marketing and pricing of mainframe software. However, the availability 
and pricing of middleware and other program products is a critical factor affecting the growth and use of 
mainframes. 
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1.9.2 VSE 


As acontrol program, z/VM is a hypervisor because it runs other operating systems in the 
virtual machines it creates. The control program artificially creates multiple virtual 
machines from the real hardware resources. To the user it appears as if they have 
dedicated use of the shared real resources. The shared real resources include printers, 
disk storage devices, and the CPU. 


The control program ensures data and application security among the virtual machines, 
which are called guest systems. The real hardware can be shared among the guests, or 
dedicated to a single guest for performance reasons. The systems programmer allocates 
the real devices among the guests. For most customers, the use of guest systems allows 
them to avoid having larger hardware configurations. 


The second major component of z/VM is CMS or Conversational Monitor System. This 
component of z/VM runs in a virtual machine and provides the both an interactive 
end-user interface and the general z/VM application programming interface. 


Virtual Storage Extended (VSE) is popular with users of smaller mainframe computers. 
Many of these customers eventually migrate to z/OS when they grow beyond the 
capabilities of VSE. 


Compared to z/OS, the VSE operating system provides a smaller, less complex base for 
batch processing and transaction processing. The design and management structure of 
VSE is excellent for running routine production workloads consisting of multiple batch 
jobs (running in parallel) and extensive, traditional transaction processing. 


In practice, most VSE users also have the z/VM operating system and use this as a 
general terminal interface for VSE application development and system management. 


This operating system was originally known as Disk Operating System (DOS), and was 
the first disk-based operating system introduced for the System 360 mainframe 
computers. DOS was seen as a temporary measure until OS/360 would be ready. 
However, many mainframe customers liked its simplicity (and small size) and decided to 
remain with it after OS/360 became available. DOS became known as DOS/VS (when it 
started using virtual storage), then VSE/SP, and later VSE/ESA. The name VSE is often 
used collectively to reference any of the more recent versions. 


1.9.3 Linux for zSeries 


Several Linux distributions can be used on a mainframe. These distributions are not from 
IBM but their use is supported by IBM. Two generic names are used for these 
distributions: 


> Linux for S/390 (uses 31-bit addressing and 32-bit registers) 
> Linux for z/Series (uses 64-bit addressing and registers). 
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1.9.4 TPF 


The phrase Linux on zSeries is used to refer to Linux running on an S/390 or zSeries 
system, when there is no specific need to refer explicitly to either the 31-bit version or the 
64-bit version. 


We assume students are generally familiar with Linux and therefore we mention only 
those characteristics that are relevant for mainframe usage. These include the following: 


> Linux uses traditional CKD disk devices and SAN-connected SCSI type devices. 
Other mainframe operating systems can recognize these drives as Linux drives, but 
cannot use the data formats on the drives. That is, there is no sharing of data between 
Linux and other mainframe operating systems. 


> Linux does not use 3270 terminals, while all other mainframe operating systems use 
3270s as their basic terminal architecture.’ Linux uses typical ASCII terminals, 
normally connected via telnet. 


> With the proper setup, a Linux system under z/VM may be quickly cloned to make 
another, separate Linux image. The z/VM emulated LAN may be used to connect 
many Linux images and to provide an external LAN route for them. Read-only file 
systems, such as a typical /usr file system, may be shared by many Linux images. 


> Linux on a mainframe operates with the ASCII character set, not the EBCDIC 
character set. The only EBCDIC involved is when writing to character-sensitive 
devices such as displays and printers. The Linux drivers for these devices handle the 
character translation. 


The Transaction Processing Facility (TPF) operating system is a special purpose system 
used by companies that require very high volume transactions, such as credit card 
companies and airlines. TPF was once known as the Airline Control Program and was 
used for airline reservation systems. It is still used for this purpose and has been extended 
for other very large reservation systems and similar high-volume transaction processing 
requirements. 


TPF can use multiple mainframes in a loosely-coupled environment to routinely handle 
tens of thousands of transactions per second while experiencing uninterrupted 
availability measured in years. Very large terminal networks, including special-protocol 
networks used by portions of the reservation industry, are common. 


1.10 Summary 


Today, mainframe computers play a central role in the daily operations of most of the 
world’s largest corporations, such as Fortune 1000 companies. While other forms of 
computing are used extensively in business in various capacities, the mainframe occupies 


7 There is a Linux driver for minimal 3270 operation, in very restrictive modes, but this is not commonly used. 


Chapter 1. Introduction to mainframe computing 1-25 


Chapter1 mainframe intro.fm Draft Document for Review December 3, 2004 3:12 pm 


1-26 


a coveted place in today’s e-business environment. In banking, finance, health care, 
insurance, utilities, government, and a multitude of other public and private enterprises, 
the mainframe computer continues to form the foundation of modern business. 


The mainframe owes much of its popularity and longevity to its inherent reliability and 
stability, a result of continuous technological advances since the introduction of 
System/360 in 1964. No other computer architecture in existence can claim as much 
continuous, evolutionary improvement, while maintaining compatibility with existing 
applications. 


The term mainframe has gradually moved from a physical description of IBM’s larger 
computers to categorization of a style of computing. One defining characteristic of the 
mainframes has been a continuing compatibility spanning decades. 


The roles and responsibilities in a mainframe IT organization are wide and varied. It 
takes a lot of different resources to keep a mainframe computer running smoothly and 
reliably. It may seem that there are far more resources needed in a mainframe 
environment than with small, distributed systems. But, if roles are fully identified on the 
distributed systems side, many of the same roles exist there as well. 


Several operating systems are currently available for mainframes. This textbook 
concentrates on one of these, z/OS. However, mainframe students should be aware of the 
existence of the other operating systems and understand their position relative to z/OS. 


Key terms in this chapter 


application architecture batch compatibility e-business 
programmer processing 


high infrastructure mainframe online platform 
availability processing 


production punched card RAS scalabilty server farm 
control (reliability, 

availability, 

and 

serviceability) 
system system systems transaction workload 
administrator operator programming processing 


1.11 Discussion questions 





1. What is a mainframe today? How did the term arise? Is it still appropriate? 
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Ds 


Why not simply change existing applications to use improved interfaces (such as 
friendlier job control language)? Why not simply support the existing characteristics 
and also support a new, better version? 


Describe how running a mainframe can be cost-effective, given the large number of 
roles needed to run a mainframe system. 


What characteristics, good or bad, exist in a mainframe processing environment 
because of the roles that are present in a mainframe shop? (Efficiency? Reliability? 
Scalability? Inefficiency?) 


Most mainframe shops have implemented very rigorous systems management, 
security, and operational procedures. Have these same procedures been implemented 
in distributed system environments? Why or why not? 


Can you find examples of mainframe use in your everyday experiences? Describe 
them and the extent to which mainframe processing is apparent to end users. You 
might, for example, find popular Web sites that rely on mainframe technology as the 
back-end server to support online transactions and databases. 
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1.12 Instructor notes 
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Refer to 1.4, “What is a mainframe?” on page 1-4 


As the performance and cost of hardware resources (such as CPU power, external storage 
media, the number and types of devices that can be attached to the CPU) improve, the 
operating system software can exploit the improved hardware. Also, continuing 
improvements in software functionality help to drive the development of each new 
generation of hardware systems. 


Refer to “Reliability, availability, and serviceability” on page 1-8 
Mean time between failure, or MTBF, refers to the availability of a computer system. The 
mainframe and its associated software has evolved to the point that customers often 
experience years of system availability between system downtime. Moreover, when the 
system is unavailable because of an unplanned failure or a scheduled upgrade, this period 
is typically very short. The remarkable availability of the system in processing the 
organization’s mission-critical applications is vital in today’s 24-hour, global economy. 


Refer to “Reliability, availability, and serviceability” on page 1-8 
Mainframe operating systems exhibit RAS characteristics through hardware and software 
features designed for reliability. These features allow a mainframe to run for months and 
even many years before needing a scheduled outage or upgrade. This section provides a 
more detailed description of the various types of mainframe RAS attributes: 


> Processor RAS. Examples of processor RAS include the following: 


— The processors (PUs) in a zSeries mainframe have dual instruction-execution 
elements that operate in parallel. Results are compared internally for almost every 
instruction. If the results do not match, the instruction is retried. 


— Ifa processor failure is sustained, the state of the processor (register contents and 
so forth) can be moved into memory (by a separate mechanism that is unlikely to 
be affected by the PU failure) and, at that point, the operating system can dispatch 
the program on a different processor. The running application is unaware of the 
processor failure and continues execution. The failed processor is taken offline 
(by the system controllers) and a spare PU (if available) is automatically brought 
online to replace it. 


— Many mainframes offer an internal battery option, which can keep the CEC 
(processors, memory, channels, but not I/O devices) operational for several 
minutes after a power failure. Many installations have an external uninterruptable 
power system (UPS) that runs the CEC and the I/O devices. 


> Memory RAS. A large amount of redundant memory exists in the system and this is 
automatically invoked to replace failing memory, with little or no disruption. 


> I/O RAS. Many of the RAS functions of I/O devices are now below the level of the 
software or application. The following elements are important: 
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— The System Assistance Processor (SAP) controls I/O operations. If a channel or 
control unit fails, and alternative channel paths exist, the SAP tries all possible 
paths to bypass problems. 


— Depending on the nature of the I/O device, a control unit can invoke many types 
of recovery without help from the SAP, operating system, or application. Disk and 
tape control units, for example, detect various types of temporary errors and 
correct them. 


— Mainframe storage devices (disks and tapes) automatically record multiple levels 
of check bits or check sums on their media and verify these bits and sums when 
reading data. Errors cause automatic retries, sometimes with additional 
mechanical actions or resets to overcome potential alignment problems. 


— Operators can take channels, paths, control units, or devices offline for repair 
actions or other reasons. Severe errors generate operator messages containing 
detailed sense information that may help the operator resolve the problem. 


— Newer disk products use internal RAID techniques, usually with hot spares. This 
is transparent to the operating system and applications. 


— Newer communications interfaces (which are combined channel, control unit, and 
device adapters in the system frame) have multiple on-board processors that 
manage many communication functions (including error recovery) without 
intervention by the SAPs, operating system, or applications. 


> Hardware Serviceability. Newer mainframes permit many hardware elements to be 
replaced without impacting system operation. For example, duplicate redundant 
power supplies exist at many levels of the system and any of these can be replaced 
without disrupting operation; larger machines use three-phase power and are 
designed to continue operating if a power phase is lost. 


Also, channels are implemented as cards that fit in slots in card cages in the processor 
box. Channel cards may be removed while the system is running. Whether this action 
is disruptive depends on the nature of the channel and whether multiple paths (from 
other channel cards) exist to the affected control units. Some channel cards contain 
multiple channels and have at least one spare channel interface that can be 
dynamically altered to replace a failing channel on the card. 


> Operating System RAS. Examples of operating system RAS include the following: 


— Significant functions of z/OS are protected by recovery routines. If a z/OS 
function abnormally ends (or ABENDs) for some reason, the recovery routine 
attempts to repair the problem and rerun the function. 


— Critical parts of the system have redundant data, such as double-threaded lists that 
can be used to reconstruct working data elements. Recovery routines can use this 
redundant information to recover from an ABEND in system routines. 


— z/OS has an architected set of recovery layers, with standard interfaces. System 
middleware use these interfaces extensively as part of their own recovery designs. 
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> Fixes. IBM provides periodic fixes (called PTFs) for z/OS and its associated software 
products. These fixes can be installed individually, in groups, or not installed at all. 
Each new release of z/OS incorporates PTFs from earlier releases. 


Refer to 1.6.3, “Scalability” on page 1-10 

As a company grows in employees, customers, and business partners, it usually needs to 
add computing resources to support business growth. One approach is to add more 
processors of the same size, with the resulting overhead in managing this more complex 
setup. Alternatively, a company can consolidate its many smaller processors into fewer, 
larger systems. With a mainframe system, many companies have significantly lowered 
their total cost of ownership, or TCO, which includes hardware and software needed to 
manage and maintain the system. 


Refer to “Typical mainframe workloads” on page 1-11 


Some trivia: The punched card was developed in 1890 by Herman Hollerith (1860-1929), 
while he worked as a statistician for the United States Census Bureau. To help tabulate 
results for the 1890 U.S. Census, Hollerith designed a paper card with 80 columns and 12 
rows; he decided to make it equal to the size of a U.S. dollar bill of that time. Data values 
were represented by holes punched into the appropriate row/column intersection in the 
card. Hollerith also designed an electromechanical device to “read” the holes in the card, 
and the resulting electrical signal was sorted and tabulated by a computing device. Mr. 
Hollerith later founded the Computing Tabulating Recording Company, which eventually 
became IBM. 


Refer to 1.8, “Roles in the mainframe world” on page 1-16 

Another job title is business systems analyst. This person is responsible for working with 
users in a particular department (accounting, sales, production control, manufacturing, 
and so on) to identify business needs and write specifications for the application 
programmers. To do so, the business systems analyst requires a broad understanding of 
the organization’s business goals, and the capabilities of the information system. 
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z/OS overview 








Objective: In working in the mainframe environment, you will need to know 
the basic features of the operating system. These architectural features allow a 
business to manage its core applications in a reliable and secure manner. 


In this chapter, you will learn: 


> Characteristics of the z/OS operating system 

> Basic concepts of z/OS virtual storage 

> Software products used with z/OS to provide a complete system 
> A brief comparison of z/OS and UNIX 
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2.1 What is an operating system? 


In simplest terms, an operating system is a collection of programs that manage the 
internal workings of a computer system. Operating systems are designed to make the best 
use of the computer’s various resources, and ensure that the maximum amount of work is 
processed as efficiently as possible. Although an operating system cannot increase the 
speed of a computer, it can maximize its use, thereby making the computer seem faster 
by allowing it to do more work in the same time period. 


A computer’s architecture consists of the functions the computer system provides. It is 
distinct from the physical design, and, in fact, different machine designs may conform to 
the same computer architecture. In a sense, the architecture is the computer as seen by the 
user such as a system programmer. For example, part of the architecture is the set of 
machine instructions that the computer can recognize and execute. 


2.2 What is z2/OS? 


2-2 


The operating system used for this course is z/OS!, the most widely used of all 
mainframe operating systems. z/OS is designed to offer a stable, continuously available 
environment for applications running on the mainframe. 


To understand how and why z/OS functions as it does, it is important to understand the 
environment in which it functions. The special features that make z/OS unique reflects 
the computer environments that z/OS manages. 


In most early operating systems, requests for work entered the system one at a time. The 
operating system processed each request or job as a unit and did not start the next job 
until the one ahead of it had completed. This arrangement worked well when a job could 
execute continuously from start to completion. But often a job had to wait for 
information to be read in from, or written out to, a device, such as a tape drive or a 
printer. Input and output (I/O) take a long time compared to the electronic speed of the 
processor. When a job waited for I/O, the processor was idle. 


Finding a way to keep the processor working while a job waited would increase the total 
amount of work the processor could do without requiring additional hardware. 


z/OS is capable of multiprogramming, or executing many programs concurrently, on 
behalf of many users at once. In multiprogramming, when a job cannot use the processor, 
the system can suspend, or interrupt, the job, freeing the processor to work on another 
job. 


' Z/OS is designed to take advantage of the IBM zSeries architecture, or zArchitecture, 
which was introduced in the year 2000. 
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z/OS makes multiprogramming possible by capturing and saving all the relevant 
information about the interrupted program before allowing another program to execute. 
When the interrupted program is ready to begin executing again, it can resume execution 
just where it left off. Multiprogramming allows z/OS to run hundreds of programs 
simultaneously for users who might be working on different projects at different physical 
locations around the world. 


z/OS can also perform multiprocessing, which is the simultaneous operation of two or 
more processors that share the various hardware resources, such as memory and external 
storage devices. 


The techniques of multiprogramming and multiprocessing make z/OS ideally suited for 
processing workloads that require many I/O operations. Typical mainframe workloads 
include long-running applications that write updates to millions of records in a database. 


By way of contrast, consider the operating system that might be used for a single-user 
computer system. Such an operating system would need to execute programs on behalf of 
one user only. In the case of a personal computer (PC), for example, the entire resources 
of the machine are often at the disposal of one user. 


Many users running many separate programs means that, along with large amounts of 
complex hardware, z/OS users need large amount of storage to ensure suitable system 
performance. Large companies run sophisticated business applications that access large 
databases and industry-strength middleware products. Such applications require the 
operating system to protect privacy among users, as well as enable the sharing of 
databases and software services. 


Thus, multiprogramming, multiprocessing, and the need for a large amount of storage 
means that z/OS must provide function beyond simple, single user applications. The 
sections that follow explain, in a general way, the attributes that enable z/OS to manage 
complex computer configurations. Subsequent portions of this textbook will explore 
these features in more detail. 


2.3 Virtual storage and other mainframe concepts 


In z/OS, each user has access to virtual storage, rather than physical storage. What do we 
mean by physical storage? There are two kinds of physical storage. The first is the 
storage within the mainframe processor itself. This storage is called real storage. The 
other kind of storage is external to the mainframe and includes storage on direct access 
devices, such as disk drives. This storage is called auxiliary storage. The processor 
accesses auxiliary storage through an input/output (I/O) channel. 


For the processor to execute a program instruction, the instruction and the data it 
references must be in real storage. The convention of early operating systems was to have 
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the entire program reside in real storage when its instructions were executing. However, 
the entire program does not really need to be in real storage when the instruction 
executes. Instead, by bringing pieces of the program into real storage only when the 
processor was ready to execute them, and moving them out to auxiliary storage when it 
didn’t need them, an operating system could execute more and larger programs 
concurrently. 


How does the operating system keep track of each program piece -- whether it is in real 
storage or auxiliary storage, and where? Physical storage is divided into separate areas, 
each the same size and accessible by a unique address. In real storage, these areas are 
called frames; in auxiliary storage, they are called slots. 


Similarly, the operating system can divide a program into pieces the size of frames or 
slots and assign each piece a unique address. This arrangement allows the operating 
system to keep track of these pieces. In z/OS, the program pieces are called pages. These 
areas are discussed further in 2.3.4, “Frames, slots and pages” on page 2-7. 


The addresses of pages are called virtual addresses. From the time a program enters the 
system until it completes, the virtual address of the page remains the same, regardless of 
whether the page is in real storage or auxiliary storage. Each page consists of individual 
locations called bytes, each of which has a unique virtual address. z/OS uses the first byte 
of the page to identify the page. 


Along with this labeling system, z/OS uses tables to determine whether a page is in real 
or auxiliary storage, and where. To find a page of a program, z/OS checks the table for 
the virtual address of the page, rather than searching through all of physical storage for it. 
z/OS then moves transfers the page into real storage or out to auxiliary storage as needed. 
This movement of pages between auxiliary storage slot and real storage frames is called 
paging. Paging is key to understanding the use of virtual storage in z/OS. 


2.3.1 What is virtual storage? 
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Virtual storage means that each running program can assume it has access to all of the 
real storage defined by the architecture’s addressing scheme. The only limit is the 
number of bits in a storage address. This ability to use a large number of storage locations 
is important because a program may be long and complex and, both the program’s code 
and the data it requires must be in real storage for the processor to access them. 


z/OS supports 64-bit long addresses, which allows a program to address up to 
18,446,744,073,709,600,000 bytes (16 exabytes) of storage locations. In reality, the 
mainframe might have much less real storage installed. How much less depends on the 
model of computer and the system configuration. 


To allow each user to act as though this much storage really exists in the computer 
system, z/OS keeps only the active portions of each program in real storage. z/OS keeps 
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the rest of the code and data in special files on auxiliary storage, which usually consists 
of a number of high-speed direct access storage devices (DASDs). 


Virtual storage, then, is this combination of real and auxiliary storage. z/OS requires 
large amounts of auxiliary storage to make virtual storage possible. z/OS uses a system of 
tables and bit settings to relate the auxiliary storage locations to real storage locations and 
keep track of the identity and authority of each program. This process is shown in more 
detail in 2.3.3, “How virtual storage works” on page 2-5. 


2.3.2 What is an address space? 


The range of virtual addresses that the operating system assigns to a user (or separately 
running program) is called an address space. This is the area of contiguous virtual 
addresses available for executing instructions and storing data. The range of virtual 
addresses in an address space starts at zero and can extend to the highest address 
permitted by the operating system architecture. 


z/OS provides each user with a unique address space and maintains the distinction 
between the programs and data belonging to each address space. z/OS also includes 
cross- memory services that permit a user to access other address spaces when necessary. 


Because it maps all of the available addresses, an address space includes system code and 
data as well as user code and data. Thus, not all of the mapped addresses are available for 
user code and data. 


The ability of many users to share the same resources implies the need to protect users 
from one another and to protect the operating system itself. Along with such methods as 
“keys” for protecting real storage and code words for protecting data files and programs, 
separate address spaces ensure that users’ programs and data do not overlap. 


In a running system, z/OS has many address spaces. There is one for each job in progress. 
There is one for each TSO/E user. TSO/E is described later in this book, but students in 
this course are TSO/E users when they log on to z/OS. 


2.3.3 How virtual storage works 


Think of virtual storage as an illusion created by the architecture, in that the system 
seems to have more memory that it really has. It is important for z/OS professionals to 
understand how the operating system makes this happen. Each user or program gets an 
address space, and each address space contains the same range of storage addresses. Only 
those portions of the address space that are needed at any one point in time are actually 
loaded into real storage. z/OS keeps the inactive pieces of address spaces in auxiliary 
storage. 


Figure 2-1 on page 2-6 shows the virtual storage concept at work in z/OS. 
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Figure 2-1 Real and auxiliary storage combine to create the illusion of virtual storage 


In the figure, observe the following: 


> An address is an identifier of a required piece of information, but not a description of 
where in real storage that piece of information is. This allows the size of an address 
space (that is, all addresses available to a program) to exceed the amount of real 
storage available. 


> All real storage references are made in terms of virtual storage addresses. 


> A hardware mechanism is used to map the virtual storage address to a physical 
location in real storage. As shown in Figure 2-1, the virtual address 10254000 can 
exist more than once, because each virtual address maps to a different address in real 
storage. 


> When a requested address is not in real storage, an interruption is signaled and the 
system brings the required instructions and data into real storage. 
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Terms: The terms real storage, real memory, central storage, and main storage are 
used interchangeably. Likewise, virtual memory and virtual storage are used 
synonymously. 


In z/OS, virtual storage is implemented through the following: 


Pages: Real storage and program address spaces are divided into units 
of 4096 bytes (four kilobytes) each called pages. 


Segment: For purposes of storage management, address spaces are 
divided into 1-megabyte units called segments. A 2-gigabyte 
address space, for example, consists of 2048 segments. 


Dynamic address translation: 
Dynamic address translation or DAT is the process by which the 
system translates a virtual address into a real address. DAT is 
performed whenever a page is brought in from auxiliary 
storage. This translation allows a single copy of the program to 
be loaded into any available real storage location. Otherwise, 
there would have to be many copies of the program, one for 
each possible frame in real storage (see Frames, slots and 
pages). Dynamic address translation or DAT is implemented by 
both hardware and software through the use of page tables and 
segment tables. 


In summary, the use of virtual storage in z/OS means that only the pieces of a program 
that are currently active need to be in real storage at processing time. The inactive pieces 
are held in auxiliary storage. 


2.3.4 Frames, slots and pages 


When a program is selected for execution, the system brings it into virtual storage and 
divides it into pages of four kilobytes (4K). The system transfers the pages of a program 
into real storage for execution and transfers pages out to auxiliary storage when they are 
not needed. 


To the programmer, the entire program appears to occupy contiguous space in real 
storage at all times. Actually, not all pages of a program are necessarily in real, and the 
pages that are in real storage do not necessarily occupy contiguous space. 


The pieces of a program executing in virtual storage must be moved between real and 
auxiliary storage. To allow this, z/OS manages storage in units, or blocks, of four 
kilobytes: 


> A block of real storage is a frame. 
> A block of virtual storage is a page. 
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> A block of auxiliary storage is a s/ot. 


A page, a frame, and a slot are all the same size: each is 4096 bytes (four kilobytes). An 
active virtual storage page resides in a real storage frame. A virtual storage page that 
becomes inactive resides in an auxiliary storage slot (in a paging data set). Figure 2-2 
shows the relationship of pages, frames and slots in the system. 















































VIRTUAL ‘ 

i CENTRAL 

i AUXILIARY 

: F 

: : HEH 

i Jolele || | joist | 

SLOTS 

FRAMES 





PAGES 


Figure 2-2 Frames, slots and pages 


Moving pages between real storage frames and auxiliary storage slots is called paging. 
z/OS performs paging in a manner that is transparent to the user. During job execution, 
only those pieces of the application that are required are brought in, or paged in, to real 
storage. The pages remain in real storage until no longer needed, or another page is 
required by the same application or a higher priority application, and there is no empty 
real storage available. 


z/OS tries to keep an adequate supply of available real storage frames constantly on hand. 
When a program refers to a page that is not in real storage, z/OS uses a real storage page 
frame from a supply of available frames. 


When this supply becomes low, z/OS uses page stealing to replenish it. Here, z/OS takes 
a frame assigned to an active user and makes it available for other work. The decision to 
steal a particular page is based on the activity history of each page currently residing in a 
real storage frame. Pages that have not been accessed for a relatively long time are good 
candidates for page stealing. 
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z/OS uses a sophisticated paging algorithm to efficiently manage virtual storage based on 
which pages were most recently used. z/OS also uses various storage managers to keep 
track of all pages, frames and slots in the system. 


2.3.5 Storage managers 


Real storage frames, auxiliary storage slots and the virtual storage pages that they 
support, are managed by separate components of z/OS. These are the real storage 
manager, the auxiliary storage manager, and the virtual storage manager. 


The real storage manager (RSM) keeps track of the contents of real storage. It maintains 
the entries in the system’s page frame table, and in each address space’s page tables, 
which relate the virtual storage page to a slot in auxiliary storage. RSM manages paging 
activities in the system. 


The auxiliary storage manager (ASM) controls the use of page data sets on auxiliary 
storage devices. Page data sets contain slots representing virtual storage pages that are 
not currently occupying a real storage frame. (Page data sets also contain slots 
representing pages that do occupy a real storage frame, but, because the frame’s contents 
have not changed, the slots are still valid.) 


The virtual storage manager (VSM) keeps track of the map of virtual storage for each 
address space. Within an address space, VSM keeps track of which areas are allocated for 
use by the user of the address space, and which areas are currently unused. z/OS 
customers can modify how certain virtual storage areas are to be allocated through the 
use of system parameter settings (not discussed in this chapter). These parameters have 
an impact on real storage use and overall system performance. 


The amount of real storage needed to support the virtual storage in an address space 
depends on the portion of the application being used (the working set), and this varies 
over time. A user does not automatically have access to all the virtual storage in the 
address space. Requests to use a range of virtual storage are checked for size limitations 
and then necessary paging table entries are constructed to create the requested virtual 
storage. 


2.3.6 Brief history of virtual storage and addressability 


In 1970, IBM introduced System/370, the first of its architectures to use virtual storage 
and address spaces. Since that time, the operating system has changed in many ways. 
One key area of growth and change is addressability. 


System/370 defined storage addresses as 24 bits in length, which meant that the highest 
accessible address was 16,777,216 bytes (or ae bytes). The use of 24-bit addressability 
allowed MVS/370, the operating system at that time, to allot to each user an address 
space of 16 megabytes. 
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Over the years, as MVS/370 gained more functions and was asked to handle more 
complex applications, even access to 16 megabytes of virtual storage fell short of user 
needs. Users ran out of space; they needed more available virtual storage. 


With the release of the System/370-XA architecture in 1983, IBM extended the 
addressability of the architecture to 31-bits. With 31-bit addressing, the operating system 
(now called MVS Extended Architecture or MVS/XA) increased the addressability of 
virtual storage from 16 megabytes to two gigabytes (2 GB). In other words, MVS/XA 
provided an address space for users that was 128 times larger than the address space 
provided by MVS/370. 


The new architecture did not require customers to change existing application programs. 
To maintain compatibility for existing programs, MVS/XA recognized both a 24-bit and 
a 31-bit addressing scheme. MVS/XA remained compatible for programs originally 
designed to run with 24-bit addressing on MVS/370, while allowing application 
developers to write new programs to exploit the 31-bit technology. 


To preserve compatibility between the different addressing schemes, MVS/XA did not 
use the high order bit of the address (Bit 32) for addressing. Instead, MVS/XA reserved 
this high order bit to indicate how many bits would be used to resolve an address: 31-bit 
addressing (Bit 32 on) or 24-bit addressing (Bit 32 off). 


The 16-megabyte (16MB) address became the dividing point between the two 
architectures and is commonly called The Line (see Figure 2-3 on page 2-11). 
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Figure 2-3 Address space on IBM System/370 architecture 


With the release of zSeries mainframes and z/Architecture in the year 2000, IBM further 
extended the addressability of the architecture to 64-bits. 


With 64-bit addressing, the potential size of a z/OS address space expands to a size so 
vast that we need new terms to describe it. Each address space, called a 64-bit address 
space, is 16 exabytes in size; an exabyte is slightly more than one billion gigabytes. The 
new address space has logically 2% addresses. It is 8 billion times the size of the former 
2-gigabyte address space. The number is 16 with 18 zeros after it: 
16,000,000,000,000,000,000 bytes, or 16 exabytes. 


We say that the potential size is 16 exabytes because z/OS, by default, continues to create 
address spaces with a size of 2 GB. The address space exceeds this limit only if a 
program running in it allocates virtual storage above the 2-gigabyte address. If so, the 
z/OS operating system increases the storage available to the user from two gigabytes to 
16 exabytes. 
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Programs running on z/OS and zSeries mainframes can run with 24, 31, or 64-bit 
addressing (and can switch among these if needed). Programs can use a mixture of 
instructions with 64-bit operands or 32-bit operands or other operands. 


For compatibility, the layout of the storage areas for an address space is the same below 
2 GB, providing an environment that can support both 24-bit and 31-bit addressing. The 
area that separates the virtual storage area below the 2 GB address from the user private 
area is called the bar, as shown in Figure 2-4. 
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Figure 2-4 64-bit address space map 


0 to 2**31 The layout is the same; see Figure 2-4. 


2**31 to 2**32 From 2 GB to 4 GB is considered the bar. Below the bar can be 
addressed with a 31-bit address. Above the bar requires a 64-bit 
address. 


2**31 -2**41 The low non-shared area (user private area) starts at 4 GB and 
extends to 2**41. 


2**41 - 2**50 Shared area (for storage sharing) starts at 2**41 and extends to 
2**50 or higher, if requested. 
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2**50 - 2**64 High non-shared area (user private area) starts at 2**50 or wherever 
the shared area ends and goes to 2**64. 


2.3.7 z/OS system address spaces 


Many of the z/OS system functions run in their own address spaces. When you start 
z/OS, for example, master scheduler initialization routines initialize system services such 
as the system log and communications task, and start the master scheduler address space 
(*MASTER*). Each address space created has a number associated with it, called the 
address space ID (or ASID). 


Because the master scheduler is the first address space created in the system, it becomes 
address space number one (ASID=1). Other system address spaces are then started 
during the initialization process of z/OS. 


Figure 2-5 shows four “types” of address spaces commonly found in an active z/OS 


system. Examples of system and subsystem address spaces are indicated, as well as user 
address spaces (TSO LOGON) and running jobs (Batch Job). 
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Figure 2-5 z/OS address spaces 
At this point, you need only understand that z/OS and its related subsystems require 


address spaces of their own to provide a functioning operating system. A short 
description of each type of address space follows: 
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> System. z/OS system address spaces are started after initialization of the master 
scheduler. These address spaces perform functions for all the other types of address 
spaces that start in a z/OS system. 


> Subsystem. z/OS requires the use of various subsystems, such as a primary job entry 
subsystem or JES (described later in Chapter Appendix 5, “Batch processing, JCL, 
and Job Management with JES”). 


> TSO/E logon. TSO/E address spaces is created for every user who logs on to z/OS 
(described in Chapter Appendix 3, “TSO/E and ISPF: User interactive facilities of 
z/OS”). 


> Batch job. An address space is created for every batch job that runs on z/OS. Batch 
job address spaces are started by the job entry subsystem. 


2.3.8 What’s in an address space? 
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Another way of thinking of an address space is as a programmer’s map of the virtual 
storage available for code and data. An address space provides each programmer with 
access to all of the addresses available through the computer architecture. 


z/OS provides each user with a unique address space and maintains the distinction 
between the programs and data belonging to each address space. Because it maps all of 
the available addresses, however, an address space includes system code and data as well 
as user code and data. Thus, not all of the mapped addresses are available for user code 
and data. 


Understanding the division of storage areas in an address space is made easier with a 
diagram. The diagram shown in Figure 2-6 on page 2-15 is more detailed than needed for 
this part of the course, but is included here to show that an address space maintains the 
distinction between programs and data belonging to the user, and those belonging to the 
operating system. 
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Figure 2-6 Storage areas in an address space 


Given the vast range of addressable storage in an address space, the drawing in 
Figure 2-6 is not to scale. 


Figure 2-6 shows five address spaces, USER2, PAYROLL, USER1, TCPIP, and JES2. In 
the figure, USER1 and USER2 are TSO/E users, PAYROLL is a batch job, and TCPIP 
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and JES2 are z/OS subsystem. These categories are implied by the names only; there is 
nothing in the actual address spaces to enforce such categories. 


The common area is shown below one of the address spaces, but this might give an 
inaccurate impression. The same common area is part of every address space; the 
illustration method used here is intended to emphasize that there is only one instance of 
the common area. Generally speaking, the common area might be compared to a large 
shared segment or shared storage area in a UNIX system. 


There are actually many more subdivisions within an address space than are shown in 
Figure 2-6 on page 2-15, but this figure lists the major areas: 


> PSA or program save area. This is a 4K block (or 8K in 64-bit mode) that is unique to 
each processor. The PSA always starts are real address 0 and virtual address 0 and is 
used only by the operating system. 


> Private Area. This is typically between five and 10 MB and is the space left over after 
the common area below the 16 MB line is allocated. It is intended for user programs 
and data. The private area is usable in 24, 31, and 64-bit addressing modes. Many 
z/OS functions run in 24-bit addressing mode and are executed in this area. 


> Common area, which is further divided as follows: 
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CSA or the Common Storage Area. This is available only to authorized programs 
(programs with a greater degree of security) and provides shared working areas 
across all normal address spaces. The CSA is usable in any addressing mode 
because it is below the 16 MB line. 


LPA or the Link Pack Area. This contains reentrant programs. A program is 
reentrant if the same copy of the program can be used by two or more tasks 
simultaneously. Because programs in the LPA are already resident in virtual 
storage, they can be used by any program in any address space with minimal 
overhead. Programs in LPA can be used in any addressing mode. There are 
several subdivisions of LPA for special use. 


SQA or the System Queue Area. This is a work area for operating system data and 


other data that must be available from any address space. It is usable in any 
addressing mode. 


Nucleus. This contains basic operating system routines. 


Extended Nucleus. This part of the nucleus is usable only in 31- and 64-bit 
addressing mode. Much of the nucleus was rewritten in 31-bit mode and most of 
the system nucleus is here. 


Extended SQA. This portion of the System Queue Area is usable only in 31- and 
64-bit addressing modes. Over time, most of z/OS has been rewritten to use data 
in this area. 

Extended LPA. This part of LPA contains programs that can run in 31- or 64-bit 

addressing modes. 
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— Extended CSA. This part of CSA provides shared working storage for authorized 
programs running in 31 or 64-bit addressing mode. 


> Extended Private Area. This is approximately 2 GB minus the size of all the other 
areas below the 31-bit line. It is available to user programs and data that can be used 
in 31- or 64-bit mode. 


> Unused area. This is a 2-GB area just above the 2-GB line. Only programs running in 
64-bit addressing mode can reference this area. 


> High private area above. This is a large addressing area, which is managed differently 
than real storage below the 2 GB line. 


Generally speaking, programs that operate in 64-bit addressing mode are not as 
commonly used by programmers as 31-bit programs. Most 64-bit programs run as part of 
larger middleware applications, such as database managers (middleware is described 
later in this textbook). As a result, many address space diagrams, including several used 
in this book, ignore the existence of the address range above 2 GB unless specifically 
discussing the use of 64-bit addressing. 


The address space diagram shown in Figure 2-7 is more detailed than needed for most 
discussions. Typically, a simpler illustration such as Figure 2-7 is adequate for most 
discussions of address spaces. 


USER2 PAYROLL USER1 TCP/IP JES2 


z/OS System 





Figure 2-7 Simplified diagram of z/OS address spaces 


This is a more conceptual illustration of address spaces. It does not attempt to detail the 
address ranges involved and places all of the common area into a simple box, the z/OS 
system. 


2.4 Summary of Z/OS facilities 


An extensive set of system facilities and unique attributes makes z/OS well suited for 
processing large, complex workloads -- those that require many I/O operations, access to 
large amounts of data, and comprehensive security. Typical mainframe workloads 
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include long-running applications that write updates to millions of records in a database, 
and online applications that can serve many thousands of users concurrently. 


Figure 2-8 provides a “snapshot” view of the z/OS operating environment. 
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Figure 2-8 What's in an operating system? 


These facilities are explored in greater depth in the remaining portions of this textbook, 
but are summarized as follows: 


> An address space describes the virtual storage addressing range available to an online 
user or a running program. 


> Two types of physical storage are available: real or central storage (CS), and auxiliary 
storage (AUX). Real storage is also referred to as real memory or real storage. 


> z/OS moves programs and data between real storage and auxiliary storage through a 
process called paging. 
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z/OS dispatches work for execution. That is, it selects programs to be run based on 
priority and ability to execute and then loads the program and data into real storage. 
All program instructions and data must be in real storage when executing. 


An extensive set of facilities manages data sets stored on direct access storage device 
(DASD) or tape. 


Operators use consoles to start (or IPL) z/OS, enter commands, and manage the 
operating system. 


z/OS provides operational facilities such as security, recovery, data integrity and job 
management. 


2.5 Defining characteristics of Z/OS 


The defining characteristics of z/OS are summarized, as follows: 


> 


The system is designed to preserve data integrity, regardless of how large the user 
population might be. z/OS prevents users from accessing or changing any objects on 
the system, including user data, except by the system-provided interfaces that enforce 
authority rules. 


The system is designed to manage a large number of concurrent batch jobs, with no 
need for the customer to externally manage workload balancing or integrity problems 
that might otherwise occur due to simultaneous and conflicting use of a given set of 
data. 


The system provides terminal interfaces and facilities for various types of full-system 
users that is compatible with the automatic system management functions that apply 
to batch jobs. 


The security design extends to system functions as well as simple files. Security can 
be incorporated into applications, resources and user profiles. 


The system allows multiple communications subsystems at the same time, permitting 
unusual flexibility in running disparate communications-oriented applications (with 
mixtures of test, production, and fall-back versions of each) at the same time. For 
example, multiple TCP/IP stacks can be operational at the same, each with different 
IP addresses and serving different applications. 


The system provides extensive software recovery levels, making unplanned system 
restarts very rare in a production environment. System interfaces allow application 
programs to provide their own layers of recovery. These interfaces are seldom used 
by simple applications but are normally used by more sophisticated applications. 


The system is designed to routinely manage very disparate workloads, with automatic 
balancing of resources to meet production requirements established by the system 
administrator. 
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> 


The system is designed to routinely manage large I/O configurations that might 
extend to thousands of disk drives, multiple automated tape libraries, many large 
printers, large networks of terminals, and so forth. 


The system is controlled from one or more operator terminals, or from application 
programming interfaces (APIs) that allow automation of routine operator functions. 


The operator interface is a critical function of z/OS. It provides status information, 
messages for exception situations, control of job flow, hardware device control, and 
allows the operator to manage unusual recovery situations. 


2.6 Program products for z/OS 
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An installed z/OS system usually contains additional program products (priced products) 
that are needed to create a practical working system, such as a security manager product 
and a database manager product. When talking about z/OS, people often assume the 
inclusion of these program products. This is normally apparent from the context of a 
discussion, but it might sometimes be necessary to ask whether a particular function is 
part of “the base z/OS” or is an add-on product. 


We won’t attempt to list all of the z/OS program products in this book (hundreds exist), 
however, some common choices include: 


> 


A security system. z/OS provides a framework for customers to add security through 
the addition of a security management product (IBM’s program product is Resource 
Access Control Facility or RACF). Other non-IBM security system program products 
are also available. 


Compilers. z/OS includes an assembler and a C compiler. Other compilers, such as 
COBOL, are offered as separate products. 


A relational database such as DB2. Other types of database products, such as 
hierarchical databases, are also available. 


Transaction processing facilities. In this area, IBM offers several, including: 


— Customer Information Control System (CICS) 
— Information Management System (IMS) 
— WebSphere. 


A sort program. Fast, efficient sorting of large amounts of data is highly desirable in 
batch processing. IBM and other vendors offer sophisticated sorting products. 


A large variety of utility programs. For example, the System Display and Search 
Facility (SDSF) program that we use extensively in this course to view output from 
batch jobs is a program product. Not every installation purchases SDSF and there are 
alternative products available. 


A large number of other products are available from various independent software 
vendors (commonly called JSVs in the industry). 
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2./ Middleware for z/OS 


Middleware is typically something between the operating system and an end user or 
end-user applications. It supplies major functions not provided by the operating system. 
As commonly used the term usually applies to major software products such as a 
database managers, transaction monitors, web servers, and so forth. Subsystem is another 
term often used for this type of software. These are usually program products although 
there are notable exceptions, such as the HTTP server from Apache. 


z/OS is a base for using many middleware products and functions. It is commonplace to 
run a variety of diverse middleware functions, with multiple instances of some. The 
routine use of wide ranging workloads (mixtures batch, transaction, Web, database, 
interactive) is characteristic of z/OS. 


Typical z/OS middleware includes: 


Database systems 

Web servers 

Message queueing and routing functions 
Transaction managers 

Java virtual machines 

XML processing functions. 


vvvvvy 


A middleware product often includes an application programming interface (API). In 
some cases, applications are written completely to this middleware API while in other 
cases it is used only for unique purposes. Some examples of mainframe middleware APIs 
include: 


> The WebSphere suite of products, which provide a complete API that is portable 
across multiple operating systems. Among these, WebSphere MQ provides 
cross-platform APIs and inter-platform messaging. 


> The DB2 database management product, which provides an API (expressed in the 
SQL language) that is used with many different languages and applications. 


A Web server is considered to be middleware and Web programming (Web pages, CGIs, 
and so forth) are largely coded to the interfaces and standards presented by the Web 
server instead of the interfaces presented by the operating system. Java is another 
example in which applications are written to run under a Java Virtual Machine (JVM)* 
and are largely independent of the operating system being used. 


? A JVM is not related to the virtual machines created by z/VM. 
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2.8 Interfaces for Z/OS developers 


When operating systems are developed to meet the needs of the computing marketplace, 
applications are written to run on those operating systems. Over the years, many 
applications have been developed that run on z/OS and, more recently, UNIX. To service 
customers that purchase UNIX applications, z/OS contains a full UNIX operating system 
in addition to its traditional MVS system. 


The most common interface for z/OS developers is through TSO/E and its panel-driven 
interface ISPF using a 3270 terminal. Generally, developers use 3270 terminal emulators 
running on personal computers, rather than actual 3270 terminals. Emulators can provide 
developers with auxiliary functions, such as multiple sessions and uploading and 
downloading code and data from the PC. 


Development on z/OS typically involves the use of a line editor to manipulate source 
code files, the use of batch jobs for compilation, and a variety of mechanisms for testing 
programs. Interactive debuggers, based on 3270 terminal functions, are available for 
common languages. 


Development using only the z/OS UNIX portion of z/OS can be through telnet sessions 
(from which vi is available) through 3270 and TSO/E using other editors, or through X 
windows sessions from personal computers running X servers. The X server interfaces 
are less commonly used. 


Alternate methods are available in conjunction with various middleware products. For 
example, the WebSphere products provide GUI development facilities for personal 
computers. These facilities integrate TCP/IP links with z/OS to automatically invoke 
mainframe elements needed during development and testing phases for a new 
application. 


2.9 A brief comparison of z/OS and UNIX 
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What would we find if we compared z/OS and UNIX? In many cases, we’d find that 
quite a few concepts would be mutually understandable to users of either operating 
system, despite the differences in terminology. 


For experienced UNIX users, Table 2-1 on page Chapter 2.-23 provides a small sampling 
of familiar computing terms and concepts. As a new user of z/OS, many of the z/OS 
terms will sound unfamiliar to you. As you work through this course, however, the z/OS 
meanings will be explained and you will find that many elements of UNIX have analogs 
in z/OS (a more comprehensive mapping of UNIX and z/OS terms is provided in 
Appendix Appendix D, “z/OS—UNIX table’). 
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Table 2-1 Mapping UNIX to z/OS terms and concepts 


Start the operating system IPL (initial program load) the system. 


Virtual storage given to each Users get whatever virtual Users each get an address space, a 

user of the system storage they need to range of addresses extending to two 
reference, within the limits of | gigabytes of virtual storage (though 
the hardware and the some of this storage contains system 
operating system. code that is common for all users). 


Data format Byte orientation; Record orientation; often an 80-byte 
organization of the data is record, reflecting the traditional 
provided by the application. punched card image. 


System configuration data The /etc file system controls Parameters in parmlib control how the 
characteristics. system IPLs and how address spaces 
behave. 


Scripting languages Shell scripts, Perl, awk, and CLISTS (command lists) and REXX 
other languages execs 


Smallest element that A thread. The kernel supports | A task. The z/OS base control 
performs work multiple threads. program (BCP) supports multiple 
tasks. 


A long-running unit of work A started task or a long-running job 


Order in which the system Programs are loaded from the | The system searches the following 
searches for programs to run. file system according to the libraries for the program to be loaded: 
user’s PATH environmental TASKLIB, STEPLIB, JOBLIB, 
variable (a list of directories LPALST and LNKLST. 
to be searched). 


Using the system interactively | Users /ogin to systems and Users /og on to the system through 
execute shell sessions in the TSO/E and its panel-driven interface, 
shell environment. They can ISPF. A user ID is limited to having 
issue the rlogin or telnet only one logon session active at a 
commands to connect to the time. 
system. Each user can have 
many login sessions open at 
once. 


Editing data or code Many editors exist, suchas vi, | ISPF editor 
ed, sed, and emacs 
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Specifying a source and stdin and stdout SYSIN and SYSOUT - 
destination for input and > SYSUTI and SYSUT2 is used 
output data for utilities 
> SYSTSIN and SYSTSPRT is 
used for TSO/E users 


Managing programs The ps shell command allows | SDSF allows users to view and 
users to view processes and terminate their jobs. 
threads, and kill jobs through 
the kill command. 





2.10 Summary 


An operating system is a collection of programs that manage the internal workings of a 
computer system. The operating system used for this course is z/OS, the most widely 
used mainframe operating system. 


The z/OS operating system’s use of multiprogramming and multiprocessing, and its 
ability to access and manage enormous amount of storage and I/O operations makes it 
ideally suited for running mainframe workloads. 


The concept of virtual storage is central to z/OS. Virtual storage as an illusion created by 
the architecture, in that the system seems to have more storage that it really has. Virtual 
storage is created through the use of tables to map virtual storage pages to pages in real 
storage or slots in auxiliary storage. Only those portions of a program that are needed at 
any one point in time are actually loaded into real storage. z/OS keeps the inactive pieces 
of address spaces in auxiliary storage. 


z/OS is structured around address spaces, which are ranges of addresses in virtual 
storage. Each user of z/OS gets an address space containing the same range of storage 
addresses. 


In common usage the terms real storage, real memory, central storage, and real storage 
are used as synonyms and are used interchangeably. Likewise, virtual memory and 
virtual storage are used interchangeably. 


The amount of real storage needed to support the virtual storage in an address space 
depends on the working set of the application being used, and this varies over time. A 
user does not automatically have access to all the virtual storage in the address space. 
Requests to use a range of virtual storage are checked for size limitations and then 
necessary paging table entries are constructed to create the requested virtual storage. 
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Programs running on z/OS and zSeries mainframes can run with 24, 31, or 64-bit 
addressing (and can switch among these if needed). Programs can use a mixture of 
instructions with 64-bit operands or 32-bit operands or other operands. 


Mainframe operating systems seldom provide complete operational environments and 
depend on program products for middleware and other functions. Many vendors, 
including IBM, provide middleware and various utility products. 


Middleware is a relatively recent term and can embody several concepts at the same time. 
A common characteristic of middleware is that it provides a programming interface and 
applications are written (or partly written) to this interface. 


Key terms in this chapter 


address space addressability auxiliary dynamic address 
storage translation 
(DAT) 


frame input/output middleware multiprocessing 
(VO) 

multiprogrammi | page / paging program real storage 

ng product 


2.11 Discussion questions 


I 


4. 





z/OS offers 64-bit addressing. Suppose you want to use this capability to work with a 
large virtual storage area. You would use the proper programming interface to obtain, 
say, a 30 GB area of virtual storage and you might write a loop to initialize this area 
for your application. What are some of the probable side effects of these actions? 
When is this design practical? What external circumstances need to be considered? 
What would be different on another platform, such as UNIX? 


Why was moving programs and data blocks from below the line to above the line so 
complicated? How can this be done without breaking compatibility with existing 
applications? 


ISPF is acommonly used program. When you execute ISPF, where (in memory) is 
the ISPF program? 


An application program can be written to run in 24, 31, or 64-bit addressing mode. 
How does the programmer select this? In a high-level language? In assembler 
language? You have started using ISPF. What addressing mode is it using? 
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5. 


Will more real storage allow a system to run faster? What measurements indicate that 
more real storage is needed? When is no more real storage needed? What might 
change this situation? 


If the current z/OS runs only in zArchitecture mode, why do we mention 24, 31, and 
64-bit operation? Why mention 32-bit operands? 


Why bother with allocation for virtual storage? Why not build all the necessary 
paging tables for all of virtual storage when an address space is first created? 


Why are program products needed? Why not simply include all the software with the 
operating system? 


“WebSphere provides a complete application API that is uniform across platforms.” 
Discuss the pros and cons of this approach. 


2.12 Demonstrations 
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1, 


Demonstrate a standard ISPF edit, submit, check cycle on a 3270. Briefly describe 
this here. 


The instructor can display the names of most active address spaces, with a variety of 
statistics about CPU and real storage usage. There are many tools for displaying such 
information, such as the DA (Display Active) option of the SDSF product. The DA 
display also shows the working set of each address space. 


A user must have sufficient authority to display information about other users. 


Use the operator console to display information about the current status of the z/OS 
system (running jobs, I/O devices, JES2 resources) 


D M=STOR Display the amount of real storage available to the system 
DA,L Display the active address spaces 

$D Q 

D U,DASD, ONLINE 

D M=CPU 


z/OS real storage is divided into frames of 4K each, enough to hold one page. When 
active address spaces need more real storage, z/OS pages out infrequently used 
storage frames to make them available for use. z/OS uses paging data sets allocated 
on DASD containing 4K slots of storage to hold these paged out frames temporarily. 
In z/OS, the Pageable Link Pack Area (PLPA) contains programs that can be paged 
out. To check the paging activity of your system, enter the following commands: 


— D ASM 
— D ASM,PLPA 


¢ How many slots are allocated to hold paged out PLPA frames? 
¢« How many have been used? 
« What is the name of the paging data set? 
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* On which direct access storage device (DASD) volume does it reside? 


z/OS can also page out the common storage area (CSA). To see for yourself, enter the 
following command: 


— D ASM, COMMON 
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2.13 Instructor notes 


Refer to 2.1, “What is an operating system?” on page 2-2 
How to begin this chapter? Some suggestions follow. 


Overview of Operating Systems Concepts 
The definition of a computer operating system has evolved over time, and has varied 
among computer manufacturers. Some consider an operating system to be just the system 
control program or SCP (in z/OS, this is called the base control program or BCP), while 
others include additional software programs to manage: 


> Directly attached physical devices 

> Basic data record processing 

> Common macros and utilities 

> Transmission of data over various communication protocols with I/O devices. 

The history of systems development in general, and z/OS in particular, has been 
characterized by functional advances in operating systems that relieved the application 
programmer of basic system software administrative duties, to allow this person to more 
easily implement the business requirements. 


2/OS Implementation of the von Neumann Architecture 


IBM mainframes, and almost all other computers, are based in part on the ideas proposed 
by John von Neumann (1903-1957), an early pioneer in computing. Von Neumann 
outlined a computer architecture that followed three major characteristics: 


1. Stored Programming Concept. The computing device stores both data and 
instructions in its internal memory. The only distinction between data and instructions 
is when they are brought into the real storage: During the instruction cycle or during 
the data cycle. In earlier architectures, the data and instructions were stored 
separately. Most importantly, both the data and the instructions must be in real 
(physical) storage for a program to be executable. 


2. Instructions are executed sequentially, but can be conditionally executed, or they can 
cause a branch to (skip to) instructions elsewhere. 


3. There are four major subsystems in the von Neumann architecture: 


a. Internal (or real) storage 

b. Arithmetic / Logic Unit (ALU) that contains the registers and circuitry needed to 
perform arithmetic and logic (comparison) functions 

c. Control unit that consists of a program instruction counter and the instruction 
decoder circuitry 

d. Various I/O control units, communication devices, and external storage devices. 


The central processing unit (CPU) usually consists of an ALU and the control unit. 
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Corresponding to the von Neumann Architecture, operating systems such as z/OS 
include the following major functional components. 


1. Storage manager for real and virtual storage 


2. Processor manager for the general and special purpose registers, the instruction 
counter, and the ALU. 


3. Device manager for the externally attached devices and their control units 


4. File manager for all basic file operations: open, create, read, write, and update 
privileges, and close. 


Operating systems based on the von Neumann architecture also share other major 
functions, as follows: 


1. Master scheduler and controller for all tasks. 


2. Dispatcher that initiates and dispatches (releases) tasks that have been scheduled for 
execution by the ALU and I/O controllers. Here, a queue manager maintains a list of 
tasks that are executing, ready to execute, or waiting for another task to complete. 


3. User interface that controls an individual’s access and privileges to various system 
resources. 


4. Management of system resource allocation and usage. 


5. Data manager that controls the low level physical access and operation on all data 
files and records. 


6. Most modern operating systems also provide a level of device independence. This 
insulates the application programmer from concerns about the capacity and geometry 
of the physical device. 


Algorithms for allocating hardware resources 


Different operating systems use different algorithms for allocating hardware resources 
(such as real storage and instruction processing cycles) to the many tasks that are 
dispatched. Some operating systems allocate resources equally, that is, all dispatched 
tasks receive an equal share of the available processing cycles. Other operating systems, 
such as z/OS, allocate processing cycles according to a priority algorithm. Here, a task 
receives a priority based on its importance in relation to the other dispatched tasks 
(importance of the user, the work requested, and so on). Other scheduling algorithms 
might consider the expected duration of the task (shorter tasks have a higher priority than 
longer tasks) or when the tasks entered the scheduling queue. 


Development of early mainframe operating systems 


You might want to summarize a lecture on operating systems development: How 
applications were executed without an operating system, or how MVS evolved into z/OS. 
z/OS is also known by many former names. The original name of the operating system, 
introduced in 1964, was OS/360. Subsequent names included: PCP, MFT, MVT, SVS, 
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MVS, MVS/XA, MVS/ESA, and OS/390. IBM has changed the name many times, 
usually to denote a major technical advance.* The most common of these older names is 
Multiple Virtual Storage (MVS).4 - refer to Appendix F, “A Little Bit of IBM Mainframe 
History” 


Different levels of operating system function 

While there is not universal agreement regarding definitions and terminology, most 
mainframe professionals use the following as a working understanding of the levels of 
operating system functions. Often the concept and content of the different levels have 
been “bundled and unbundled” over the years for marketing and pricing reasons, or to 
exploit certain hardware functional features. 


1. A small program is initialized when electrical power to the system is first turned on. 
This is called the bootstrap program or BIOS (Basic Input Output System). The 
bootstrap program is usually created by the hardware manufacturer; its purpose is to 
identify the presence, availability and location of certain physical devices. The 
bootstrap program resides in protected (read-only) and non-volatile storage. In 
non-volatile storage, data is not lost when the power is turned off. When started, the 
bootstrap program searches for the base control program (BCP), loads it, and then 
passes control to it. 


2. The BCP consists of programs that perform the major functions described earlier 
(master controller and dispatcher, user interface, resource allocation and 
management). 


3. The operating system includes the BCP and additional programs to manage the 
system programming libraries, certain lower level file data access and storage utilities 
(such as VSAM), a second generation, hardware specific machine language (such as 
Assembler) and job control language interface. 


4. Lastly, there are many software programs collectively known as middleware (see 2.7, 
“Middleware for z/OS” on page 2-21). These programs are usually provided by the 
mainframe vendor or independent software vendors (ISVs). 


Refer to 2.2, “What is Z/OS?” on page 2-2 


Reviewing the earlier discussion, the key z/OS characteristics include the following 
1. Master Scheduler and Dispatcher: 


The system is designed for managing a large number of concurrent batch jobs, with 
no need for the customer to externally manage workload balancing or integrity 
problems that might otherwise occur due to simultaneous and conflicting use of a 
given set of data. 


3 For more information about earlier operating systems, see Appendix F, “A Little Bit of IBM 
Mainframe History”. 


oe component of z/OS is still named MVS, but we ignore this detail here. 
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The system allows multiple communications subsystems at the same time, permitting 
unusual flexibility in running disparate communications-oriented applications (with 
mixtures of test, production, and fall-back versions of each) at the same time. For 
example, multiple TCP/IP stacks can be operational at the same, each with different 
IP addresses and serving different applications. 


The system is designed to routinely manage very disparate workloads, with automatic 
balancing of resources to meet production requirements established by the system 
administrator. 


2. User Interface. The operator interface is a critical function of z/OS. It provides status 
information, messages for exception situations, control of job flow, hardware device 
control, and allows the operator to manage unusual recovery situations. 


The system provides terminal interfaces and facilities for various types of full-system 
users that is compatible with the automatic system management functions that apply 
to batch jobs. 


The security design extends to system functions as well as simple files. Security can 
be incorporated into applications, resources and user profiles. 


The system is controlled from one or more operator terminals, or from application 
programming interfaces (APIs) that allow automation of routine operator functions. 


3. System resource allocation and management. The system allocates hardware 
resources (real storage and CPU cycles) among the dispatched tasks. Recall that 
z/OS, unlike some other operating systems, uses a priority algorithm to allocate CPU 
cycles. 


4. Data Management. The system provides basic file and record access and processing 
(data file open and close routines, record location, blocking and deblocking of 
physical records into logical records, data transfer between the external storage 
device and real storage, and so on). The system also controls the privileges an 
individual user or application can exercise (create, read, update or write, and delete). 


5. Hardware device (geometry) control and independence. The system is designed to 
routinely manage large I/O configurations that might extend to thousands of disk 
drives, multiple automated tape libraries, many large printers, large networks of 
terminals, and so forth. 


The application programmer is insulated from any concerns regarding the physical 
device geometry. For example, if the system is upgraded to use storage devices with 
larger physical record lengths and more capacity, the application programmer would 
not need to rewrite the application’s logic to use the new device. Instead, the 
application would simply need to be re-compiled. The operating system supplies 
device drivers for all supported devices. 


6. The system provides extensive software recovery levels, making unplanned system 
restarts very rare in a production environment. Also, various system interfaces allow 
application programs to provide their own layers of recovery. 
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Refer to “Vidya stprage and other mainframe concepts” on 


Discuss the aspects of z/OS that make it unique. For example, mention the use of address 
spaces in z/OS and the special advantages of this approach: Isolation of private areas in 
different address spaces that provides much of the platform’s security, yet with a common 
area accessible to every address space. 


Explain that the “Least Frequently Used” algorithm assumes that a page which has not 
been used for some time will not be used in the near future. 


Refer to “Vidya ostprage and other mainframe concepts” on 


All programs, including the operating system and application programs, must reside in 
real storage to execute. Over the years, several trends have emerged. 


1. First, there has been a remarkable, multiple orders of magnitude, improvement in the 
price / performance characteristics of the hardware. Simply stated, the cost of both 
real storage and the external storage devices has improved over one hundred fold. 
However, real storage has always, and remains, much faster than any external storage 
device. 


2. Second, individual applications have increased in complexity and size. It is not 
unusual for an application program to consist of tens of thousands of instructions. 
Moreover, the size of the logical data records has increased, and the number of logical 
data records in a physical record has also increased. Many application programs 
allow for several record buffer areas to overlap file input and output processing. 
These factors result in very large application programs. 


3. Third, much of the application programs instructions are seldom, or never, executed, 
but must be available “just in case.” For example, a batch program’s file initialization 
and end-of-file routines are normally executed just once. Exception routines for 
unusual conditions, or error processing routines, must be coded, but might not be 
needed during a normal run. It is wasteful to have this code be resident in the 
(relatively expensive) real storage. 


4. Fourth, there has been an increase in the number of applications and end users 
wanting to access the systems resources simultaneously. 


The operating system uses the relatively cheaper and slower (than real storage) auxiliary 
storage to store the application code in an area called the page data set. At job initiation, 
the operating system locates the required application program stored in the system 
library, and moves it into the page data set. 


Significantly, the application programmer is insulated from the paging process, and is 
unaware of all that the operating system is doing to efficiently manage the hardware’s 
real storage and all hundreds (or even thousands) of application programs that 
collectively require tens of thousands of 4K pages. The only impact is that any one 
program might require more elapsed time to execute. However, the installation’s total job 
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throughput is much greater, because the operating system efficiently manages and 
optimizes the hardware system resources. It is not unusual for thousands of applications 
to be simultaneously executing. 


There is a notion of the application program‘s ‘working set’. A convenient definition is 
the working set consists of 4K blocks of instructions (routines) and internal data storage 
areas (such as data constants and I/O buffer areas) that are most often used during 
execution. It probably would not include the initial housekeeping, end-of-job, and 
exception reporting routines. To achieve adequate performance and throughput, the 
applications’ working set should require the minimum number of 4K pages, and should 
not be paged out. 


The page in / page out transfer of 4K blocks of storage between auxiliary storage and real 
storage obviously requires CPU cycles to move the data, update the control block 
information, record the status of each application’s program instruction counter, its 
register values, and so on. Other resources include the storage for the auxiliary storage 
page frames, control blocks, real storage, themselves. If there is insufficient real storage 
to support the demand for virtual storage from the application programs (that is, if the 
total amount of the actively requested virtual pages is too many times larger than the 
available real storage, the situation called ‘thrashing’ results. During thrashing, an 
unacceptable percent of the total CPU cycles is spent in system overhead, rather than in 
performing the users applications. One of the system programmer’s responsibilities is to 
efficiently ‘tune’ the system to maximize the overall job throughput and minimize the 
paging overhead and avoid thrashing. 


There are two basic approaches to provide sufficient virtual storage for today’s 
environment. One could have a single, extremely large address space that would 
accommodate the sum of the maximum conceivable size of each application for the 
maximum conceivable number of applications. This might be difficult to estimate. A 
predecessor of z/OS (called Single Virtual System, or SVS) used this approach. However, 
it was soon determined that this could not accommodate the growing user application 
demands. 


Alternatively, one could have multiple fairly large address spaces, one for each 
application. The Multiple Virtual Systems (MVS) architecture was developed; it 
provided a maximum of 2-gigabyte address space for each application, and multiple 
applications. 


The operating system then must be able to manage the resource demands of multiple 
applications, z/OS uses this is a more practical approach. First, one does not need to 
estimate the total size of all of the programs that might ever execute. Second, the 
addressing component of each instruction can be limited, thus saving real storage. 
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More information about registers and the PSW 


16 General 
16 Access Purpose 16 Floating Point 
Registers (32 bits) Registers (64 bits) Registers (64 bits) 








addr of data 1 





Program Status Word (PSW) 










Virt. Instruction 
address (64-bit) 16 Control 


Registers (64 bits) 


which tables? 1 






Virtual Storage 
Data Space 








Virtual Storage 
Data Space 





Real Storage 














Up to 5 levels of 
translation tables 





Move (MVC) instruction - moves the contents of the second operand into the first operand location 


Figure 2-9 Register and PSW 


The CP provides registers to keep track of the instruction address and the storage location 
of data to be processed. 


The instruction address is found in a hardware register called the Program Status Word 
(PSW). The PSW is used to govern exactly how each instruction is executed. Each CP is 
governed by its own PSW. The PSW contains information that is required for the 
execution of the currently active program. 


Access registers are used to specify in which space (data space or address space) data is 
found 


General registers are used to address data in storage, and also used for holding user data 
Floating point registers are used to hold numeric data (in floating point form). 


Control registers are used by the operating system itself, for example, a reference to 
translation tables. 
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More information about Z/OS dispatching 
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Figure 2-10 Dispatching Work 


Different models of the z/Series hardware can have from one to ten central processors 
(CPs). Each and every CP can be executing instructions at the same time. Dispatching 
priorities determine when ready-to-execute address spaces get dispatched. 


> An address space can be in any one of four queues. 


— IN-READY - in real storage and waiting to be dispatched 

— IN-WAIT - in real storage but waiting for some event to complete 
— OUT-READY - Ready to execute but swapped out 

— OUT-WAIT - Swapped out and waiting for some event to complete 


> Only IN-READY work will be selected for dispatching. 


More information about virtual storage 

We can have a single set of page and segment tables that produce a virtual storage range 
up to the maximum address permitted by the hardware when operating in a normal user 
mode.° This would produce a single virtual storage or a single address space. We could 
have multiple sets of page and segment tables, with one set for each user, and create 
separate virtual memories for each user. This produces multiple virtual memories or 


5 This would be 16 MB, 2 GB, or 16 EB for a z/Series machine, depending on whether it is using 24, 31, or 
64-bit addressing 
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multiple address spaces. z/OS uses this design. With the appropriate use of page tables 
by the operating system, individual system users and jobs can be completely isolated 
from each other in storage. 


One of the predecessors of z/OS was SVS, for Single Virtual System. This had a single 
virtual storage (address space) in which address regions (ranges of addresses) were 
managed for various users. This version was followed by MVS, Multiple Virtual 
Systems, in which multiple address spaces became available. Some system users still use 
the term region instead of address space. 


Almost all of z/OS is pageable, including most of the nucleus code. A relatively small 
amount of nucleus code (for interrupt handling, for example) is not pageable. Also, at any 
point in time, there may be various areas fixed in storage; that is, made non-pageable. For 
example, the segment tables for an active address space must be fixed in real storage. I/O 
must be to/from real addresses, so I/O areas (“buffers”) are made temporarily 
non-pageable for the duration of the I/O operation. 


Authorized z/OS programs can fix pages in real storage, causing these pages to be 
non-pageable. They are still part of the virtual storage address space of the application 
but, as long as they are fixed, they cannot be paged out to make their real storage pages 
available for other jobs. Depending on the nature of the application, fixing selected pages 
can improve performance. Of course, fixing pages (for an application in one address 
space) might drive up paging rates for other address spaces, reducing their performance. 


This has become more of an issue in recent years, especially with transaction managers 
and database managers. These middleware applications may contain logic to manage 
page fixing. (Again, only authorized programs can do this.) System administrators may 
elect to let these applications fix large amounts of real storage, to the detriment of “less 
important” work. This can lead to considerable debate about what is “less important” 
work. 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter3 tsoe and ispf.fm 


3 


TSO/E and ISPF: User interactive 
facilities of Z/OS 








Objective: In working with z/OS operating system, you will need to know its 
user interfaces. Chief among these is TSO/E and its menu-driven interface, 
ISPF. These programs allow you to logon to the system, run programs, and 
manipulate data files. 


In this chapter, you will develop skills in TSO/E and ISPF, including: 


> Logging on to z/OS 

Executing programs from the TSO/E ready prompt 
Navigating through the menu options of ISPF 
Using the ISPF editor. 


vvyv 




















3.1 TSO overview 


Time Sharing Option/Extensions (TSO/E) allows users to create an interactive session 
with the z/OS system. TSO! provides a single-user logon capability and a basic 
command prompt interface to z/OS. 


' Most z/OS users refer to TSO/E as simply “TSO,” and that is how it is called in this 
textbook. 
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Most users work with TSO through its menu-driven interface, Interactive System 
Productivity Facility, or ISPF. This collection of menus and panels offers a wide range of 
functions to assist users in working with data files on the system. ISPF users include 
system programmers, application programmers, administrators, and others who access 
z/OS. In general, TSO and ISPF make it easier for people with varying levels of 
experience to interact with the z/OS system. 


In a z/OS system, each user is granted a user ID and a password authorized for TSO 
logon. Logging on to TSO requires a 3270 display device or, more commonly, a TN3270 
emulator running on a PC. 


During TSO logon, the system displays the TSO logon screen on the user’s 3270 display 
device or TN3270 emulator. The logon screen serves the same purpose as a Windows 
logon panel. 


The screen text layout and information are likely to be customized by the local systems 
programmer; therefore, it varies from site to site. Figure 3-1 is a typical example of a 
TSO logon screen. 


Enter LOGON parameters below: RACF LOGON parameters: 
Userid ===> ZPROF 

Password ===> New Password ===> 
Procedure ===> IKJACCNT Group Ident ===> 


Acct Nmbr ===> ACCNT# 


Size ===> 860000 
Perform ===> 
Command ===> 


Enter an 'S' before each option desired below: 
-Nomail -Nonotice -Reconnect -OIDcard 


PF1/PF13 ==> Help PF3/PF15 ==> Logoff PA1 ==> Attention PA2 ==> Reshow 
You may request specific help information by entering a '?' in any entry field 


Figure 3-1 Typical TSO/E logon screen 


Many of the screen capture examples used in this textbook show program function (PF) 
key settings. Because it is common practice for z/OS sites to customize the PF key 
assignments to suit their needs, the key assignments shown in this textbook might not 
match the PF key settings in use at your site. (A list of the PF key assignments used in 
this textbook is provided in 3.2.1, “Keyboard mapping used in this course” on page 3-8.) 
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3.1.1 Using TSO commands in native mode 


Most z/OS sites prefer to have the TSO user session automatically switch to the ISPF 
interface after TSO logon. This section, however, briefly discusses the limited set of 
basic TSO commands available independent of other complimentary programs, such as 
ISPF. Using TSO in this way is called using TSO in its native mode. 


When a user logs on to TSO, the z/OS system responds by displaying the READY prompt, 
and waits for input, such as in Figure 3-2. 


ICH700011 ZPROF LAST ACCESS AT 17:12:12 ON THURSDAY, OCTOBER 7, 2004 
ZPROF LOGON IN PROGRESS AT 17:12:45 ON OCTOBER 7, 2004 

You have no messages or data sets to receive. 

READY 


Figure 3-2. TSO logon READY prompt 


The READY prompt accepts simple line commands such as help, rename, allocate and call. 
TSO also includes a very basic line mode editor (compared to the full screen editor 
offered by ISPF). 


Figure 3-3 is an example of the line commands a user might enter at the READY prompt. 
Here, the user is entering commands to sort data. 


READY 

ALLOCATE DATASET(AREA.CODES) FILE(SORTIN) SHR 
READY 

ALLOCATE DATASET (*) FILE(SORTOUT) SHR 
READY 

ALLOCATE DATASET (*) FILE (SYSOUT) SHR 
READY 

ALLOCATE DATASET (*) FILE(SYSPRINT) SHR 
READY 

ALLOCATE DATASET(SORT.CNTL) FILE(SYSIN) SHR 
READY 


CALL ‘SYS1.SICELINK(SORT) * 


ICE143I 0 BLOCKSET SORT TECHNIQUE SELECTED 

ICEQOOI 1 - CONTROL STATEMENTS FOR Z/OS DFSORT V1R6 
SORT FIELDS=(1,3,(CH,A) 

201 NJ 

202 DC 

203 CT 

204 Manitoba 

205 AL 

206 WA 

207 ME 

208 ID 


KKK 


Figure 3-3 Using native TSO commands to sort data 
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In this example, the user entered several TSO ALLOCATE commands to assign inputs 
and outputs to the sort program. The user then entered a single CALL command to run 
the sort program. 


Each ALLOCATE command requires content (specified with the DATASET operand) 
associated with the following: 


SORTIN - in this case AREA.CODES 

SORTOUT - in this case *, which means the terminal screen 
SYSOUT 

SYSPRINT 

SYSIN. 


vvvvy 


Following the input and output allocations and the user-entered CALL command, the sort 
program displays the results on the user’s screen. As shown in Figure 3-3 on page 3-3, 
the sort fields CONTROL statement causes the results to be sorted by area code. For 
example, NJ (New Jersey) has the lowest number telephone area code, 201. 


Native TSO screen control is very basic. For example, when a screen fills up with data, 
‘***? ig displayed to indicate a full screen. Here, the user must press the Enter key to 
clear the screen of data and allow the screen to display with the remainder of the data. 


3.1.2 Using CLISTs and REXX under TSO 
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With native TSO, it is possible to place a list of commands, called a command list or 
CLIST (pronounced “see list’) in a file, and execute the list as if it was one command. 
When you invoke a CLIST, it issues the TSO/E commands in sequence. CLISTs are used 
for doing routine tasks; they enable users to work more efficiently with TSO. 


Suppose, for example, that the commands shown in Example 3-3 on page 3-3 were 
grouped in a file called AREA.CODES. The user could then accomplish the same results 
with a single command to execute the CLIST, as follows: 


EXECUTE ‘CLIST AREA.CODES’ 


TSO users create CLISTs with the CLIST command language. Another command 
language used with TSO is called Restructured Extended Executor or REXX. Both 
CLIST and REXX offer shell-script type processing. These are interpretive languages, as 
opposed to compiled languages (though REXX can be compiled as well). This textbook 
discusses CLIST and REXX in more detail in Appendix 9, “Using programming 
languages on z/OS”. 


Some TSO users write functions directly as CLISTs or REXX programs, but these are 
more commonly implemented as ISPF functions, or by various software products. CLIST 
programming is unique to z/OS, while the REXX language is used on many platforms. 
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3.2 ISPF overview 


After logging on to TSO, users typically access the ISPF menu. In fact, many use ISPF 
exclusively for performing work on z/OS. ISPF handles all of the necessary file 
allocations, program calls, and execution of interpretive routines. ISPF menus list the 
functions that are most frequently needed by online users. 


Figure 3-4 on page 3-5 shows the ISPF menu structure.. 


Primary 
option menu 


0 Settings 
1 Browse 
2 Edi 
3 Utilities 
4 DS List 
en 



















Settings View Edit Utilities Dialog Test 


/ Cursor at .. Proj Proj 1 Dataset 


Group Group 2 Library 
S Type ___ Type ___ 3 Copy/Move 
4DS List 
Other Dsn__ Other Dsn__ 














Edit Dataset 


b Display 
D Delete 
Proj 
Group 
Type ____ 


Jobin 
0 //JOB1 JOB 
0//S1 EXEC 
0//DD1 DD 





Figure 3-4 ISPF Menu Structure 


To access ISPF under TSO, the user enters a command such as ISPFPDF from the READY 
prompt to display the ISPF Primary Menu. 


Figure 3-5 on page 3-6 shows an example of the ISPF Primary Menu. 
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Menu Utilities Compilers Options Status Help 


ISPF Primary Option Menu 


Draft Document for Review December 3, 2004 3:15 pm 


Option ===> 
0 Settings Terminal and user parameters User ID . : ZPROF 

1 View Display source data or listings Time. . . : 17:29 
2 Edit Create or change source data Terminal. : 3278 
3 Utilities Perform utility functions Screen. . : 1 
4 Foreground Interactive language processing Language. : ENGLISH 
5 Batch Submit job for language processing Appl ID . : PDF 
6 Command Enter TSO or Workstation commands TSO logon : IKJACCT 
7 Dialog Test Perform dialog testing TSO prefix: ZPROF 
8 LM Facility Library administrator functions System ID : SC04 
9 IBM Products IBM program development products MVS acct. : ACCNT# 
10 SCLM SW Configuration Library Manager Release . : ISPF 5.2 
11 Workplace ISPF Object/Action Workplace 
M More Additional IBM Products 

Enter X to Terminate using log/list defaults 

Fl=Help F2=Split F3=Exit F7=Backward F8=Forward F9=Swap 


Fl0=Actions F12=Cancel 


Figure 3-5 ISPF Primary Option Menu 


The ISPF panel can be customized with additional options by the local systems 
programmer, therefore, it can vary in features and content from site to site. 


In Figure 3-6, the user has entered ‘M’ on the option command line to display “more” of 


the available menu sections in ISPF. 
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Menu Help 
IBM Products Panel 
More + 
1  SMP/E System Modification Program/Extended 
2 ISMF Integrated Storage Management Facility 
3  RACF Resource Access Control Facility 
4 HCD Hardware Configuration Dialogs 
5S SDSF Spool Search and Display Facility 
6. JEPES Interactive Problem Control System 
t. DITTO DITTO/’ESA for MYS Version 1 
8 RMF Resource Measurement Facility 
9 DFSORT Data Facility Sort 
10 OMYS MYS OpenEdition 
11 DB2 Data Base Products 
12 RRS Resource Recovery Services 
13 DB2ADM Data Base Admin Tool 
14 QMF Query Management Facility 
15 MQ WMQ Series Operations and Control 
16 FMN File Manager 3.1.Q@perations and Control 
17 WLM Workload Manager 
18 PE Performance Expert 
Option ===> 9 
Fi=Help F2=Split F3=Exit Fr=Backward F8=Forward F9=Swap 


Fi@=Actions F1i2=Cancel 


Figure 3-6 More ISPF options displayed 
In the figure, note that SORT is offered as ISPF selection ‘9’. 


Figure 3-7 on page 3-8 shows the panel that would be displayed for executing this option 
of ISPF. 
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DFSORT PRIMARY OPTION MENU 
ENTER SELECTION OR COMMAND ===> 


SELECT ONE OF THE FOLLOWING: 


0 DFSORT PROFILE - Change DFSORT user profile 
1 SORT - Perform Sort Application 
2 COPY - Perform Copy Application 
3 MERGE - Perform Merge Application 
X EXIT - Terminate DFSORT 
\nene mente nnn neem nen ne mene nen nenenennenanennnnans / 
(pes seese eset en cece seen ete eee setae ese ee cece / 


| | 
| | Licensed Materials - Property of IBM | 
| | | | 
| | 5740-SM1 (C) Copyright IBM Corp. 1988, 1992. | | 
| | All rights reserved. US Government Users | 
| | Restricted Rights - Use, duplication or | | 
| | | | 
| | || 
| | 


disclosure restricted by GSA ADP Schedule 
Contract with IBM Corp. 


USE HELP COMMAND FOR HELP; USE END COMMAND TO EXIT. 


F1=HELP F2=SPLIT F3=END F4=RETURN F5=RFIND F6=RCHANGE 
F7=UP F8=DOWN FO=SWAP F10=LEFT F11=RIGHT = F12=CURSOR 


Figure 3-7 SORT panel 


Recall that “Using TSO commands in native mode” on page 3-3 showed an example of 
how a TSO user might perform a simple sort operation by entering TSO commands in 
TSO native mode. Here, the same sort function is available through ISPF as a menu 
selectable option. Through the SORT option, the user can allow ISPF to handle the TSO 
allocations, create the SORT control statement, and call the SORT program to produce 
the results of the sort. 


Observe the keyboard program function key (PF key) selections at the bottom of each 
panel. PF3 END, returns the user to the previous panel. 


3.2.1 Keyboard mapping used in this course 


3-8 


Many of the screen capture examples used in this textbook show ISPF program function 
(PF) key settings at the bottom of the panel. Because it is common for z/OS users to 
customize the PF key assignments to suit their needs, the key assignments shown in this 
textbook might not match the PF key settings in use on your system. Actual function key 
settings vary from customer to customer. 


Table 3-1 contains some of the most frequently used PF keys and other keyboard 
functions and their corresponding keys. 
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Table 3-1 Keyboard mapping 


PA1 or Attention Alt-Ins or Esc 





PA2 Alt-Home 


Cursor movement Tab or Enter 
Clear Pause 


Page up 








Page down 


The examples in this textbook use these keyboard settings. For example, directions in 
this textbook to press “Enter” mean that the student should press the keyboard’s control 
key (or CTRL). 


3.2.2 Using PF1-HELP and the ISPF tutorial 


From the ISPF Primary Menu, press the PF1-HELP key to display the ISPF tutorial. New 
users of ISPF should acquaint themselves with the tutorial (Figure 3-8 on page 3-10) and 
with the extensive online help facilities of ISPF. 
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Tutorial --------------------- Table of Contents -------------------- Tutorial 
ISPF Program Development Facility Tutorial 


The following topics are presented in sequence, or may be selected by entering 
a selection code in the option field: 


G General - General information about ISPF 
0 Settings - Specify terminal and user parameters 
1 View - Display source data or output listings 
2 Edit - Create or change source data 
3 Utilities - Perform utility functions 
4 Foreground - Invoke language processors in foreground 
5 Batch - Submit job for language processing 
6 Command - Enter TSO command, CLIST, or REXX exec 
7 Dialog Test - Perform dialog testing 
9 IBM Products - Use additional IBM program development products 
10 SCLM - Software Configuration and Library Manager 
11 Workplace - ISPF Object/Action Workplace 
X Exit - Terminate ISPF using log and list defaults 
The following topics will be presented only if selected by number: 
A Appendices - Dynamic allocation errors and ISPF listing formats 
I Index - Alphabetical index of tutorial topics 
Fl=Help F2=Split F3=Exit F4=Resize F5=Exhelp F6=Keyshelp 


F7=PrvTopic F8=NxtTopic F9=Swap Fl0=PrvPage F1l=NxtPage F12=Cancel 


Figure 3-8 ISPF Tutorial Main Menu 
You will most likely only use a fraction of content found in the entire ISPF tutorial. 


Besides the tutorial, you can access online help from any of the ISPF panels. When you 
invoke help, you can "scroll" through information. Press the PF1-HELP key for 
explanations of common ISPF entry mistakes, and examples of valid entries. ISPF Help 
also contains help for the various functions found in the primary option menu. 


3.2.3 Navigating through ISPF menus 
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ISPF includes a text editor and browser, and functions for locating and listing data sets, 
and performing other utility functions. This textbook has not yet discussed data sets, but 
you will need at least a working understanding of data sets to begin the lab exercises in 
this chapter. 


For now, think of a data set as a file used to store data or executable code on a z/OS 
system. A data set can have a name up to 44 characters in length, such as 
ZSCHOLAR.TEST.DATA. Data sets are described in more detail in Appendix 4, “Working 
with data sets”. 


A data set name is usually segmented, with one or more periods used to create the 
separate data set qualifiers of | to 8 characters. The first data set qualifier is the high level 
qualifier or HLQ. In this example, the HLQ is the ZSCHOLAR portion of the data set name. 
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z/OS users typically use the ISPF data set list utility to work with data sets. To access this 
utility from the ISPF Primary Option Menu, select “Utilities,” then select “Dslist” to 
display the Utility Selection Panel, which is shown in Figure 3-9 on page 3-11. 


Menu RefList RefMode Utilities Help 


Data Set List Utility 





Option ===> 
blank Display data set list P Print data set list 
V Display VTOC information PV Print VTOC information 


Enter one or both of the parameters below: 
Dsname Level . . . ZPROF. 
Volume serial 

Data set list options 


Initial View. ..1 1. Volume Enter "/" to select option 
2. Space ZL Confirm Data Set Delete 
3. Attrib Z Confirm Member Delete 
4. Total Z Include Additional Qualifiers 


When the data set list is displayed, enter either: 
"/" on the data set list command field for the command prompt pop-up, 
an ISPF line command, the name of a TSO command, CLIST, or REXX exec, or 
"s" to execute the previous command. 


Fl=Help F2=Split F3=Exit F7=Backward F8=Forward F9=Swap 
Fl0=Actions F12=Cancel 


Figure 3-9 Using the Data Set List utility 


In the panel, you can use the ‘Dsname Level’ data entry field to locate and list data sets. 
To search for one data set in particular, enter the complete (or fully qualified) data set 
name. To search for a range of data sets, such as all data sets sharing a common HLQ, 
enter only the HLQ in the ‘Dsname Level’ field. 


Qualifiers can be specified fully, partially or defaulted. At least one qualifier must be 
partially specified. To search for a portion of a name, specify an asterisk (*) before or 
after part of a data set name. Doing so will cause the utility to return all data sets that 
match the search criteria. 


In the majority of ISPF panels, a fully qualified data set name needs to be enclosed in 
single quotes. Data set names not enclosed in single quotes will automatically be 
prefixed with a high level qualifier specified in the TSO PROFILE. One exception is 
ISPF option 3.4 DSLIST. Do not enclose Dsname Level in quotes on the ISPF option 3.4 
DSLIST panel. 


For example, if you enter ZPROF in the Dsname field, the utility lists all data sets with 
ZPROF as a high level qualifier. The resulting list of data set names (see Figure 3-10) 
allows the user to edit or browse the contents of any data set in the list. 
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Menu Options View Utilities Compilers Help 


DSLIST - Data Sets Matching ZPROF Row 1 of 4 

Command ===> Scroll ===> PAGE 

Command - Enter "/" to select action Message Volume 
ZPROF *ALIAS 
ZPROF .JCL.CNTL EBBER1 
ZPROF .LIB.SOURCE EBBER1 
ZPROF .PROGRAM. CNTL EBBER1 
ZPROF .PROGRAM. LOAD EBBER1 
ZPROF . PROGRAM. SRC EBBER1 


KKK AK KAKA KK ARK KRKKERKEEKERK End of Data Set List **#** eRe REAR KRR KERR RAR K ARKH 


Fl=Help F2=Split  F3=Exit F5=Rfind  F7=Up F8=Down F9=Swap 
Fl0=Left  Fll=Right F12=Cancel 


Figure 3-10 Data set list results for dsname ZPROF 
To see all of the possible actions you might take for a given data set, specify a forward 


slash (/) in the command column to the left of the data set name. ISPF will display a list 
of possible actions, as shown in (Figure 3-11). 


Menu Options View Utilities Compilers Help 


a Gk a i al i Sk Gn a i a ak ik al is st nh ye a i in ie a en Bahk a ak ak ak a a ie a SP aera eae 
D! Data Set List Actions ! Row 1 of 4 
Cc! ! ===> PAGE 
! Data Set: ZPROF.PROGRAM.CNTL ! 
c! ! Volume 
- ! DSLIST Action | ----------- 
!_. I. Edit 12. Compress ! *ALIAS 
/ | 2. View 13. Free ! EBBER1 
! 3. Browse 14. Print Index ! EBBER1 
! 4. Member List 15. Reset ! EBBER1 
a 5. Delete 16. Move RAR 
! 6. Rename 17. Copy ! 
! 7. Info 18. Refadd ! 
! 8. Short Info 19. Exclude ! 
! 9. Print 20. Unexclude 'NX' ! 
! 10. Catalog 21. Unexclude first 'NXF' ! 
! 11. Uncatalog 22. Unexclude last 'NXL' ! 
! ! 
! Select a choice and press ENTER to process data set action. ! 
! Fl=Help F2=Split F3=Exit F7=Backward ! 
! F8=Forward F9=Swap F12=Cancel ! 
Pues sseceasitecsseceseseeetsssessesetess secs sseeeetescsscescee + 
Fl=Help F2=Split  F3=Exit F5=Rfind  F7=Up F8=Down F9=Swap 


Fl0=Left F1l=Right F12=Cancel 


Figure 3-11 Displaying the Data Set List actions 


Other actions you will use frequently during this course include the following: 
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> To view a data set’s contents, enter an ‘v’ (view) in the command column 
> To edit a data set’s contents, enter an ‘e’ (edit) in the command column. 


3.2.4 Using the ISPF editor 


To edit a data set’s contents, enter an ‘e’ (edit) to the left of the data set name. In a data 
set, each line of text is known as a record. 


To edit the contents of a data set, move the cursor to the area of the record to be changed 
and type over the existing text. You can enter commands on the editor command line to 
‘find’ and ‘change’ text. To insert, copy, delete, or move text, place these commands 
directly on the line numbers where the action should occur. To commit your changes, 
enter PF3 or save. To exit the data set without saving your changes, enter Cancel on the 
edit command line. 


Figure 3-12 on page 3-13 shows the contents of data set 
ZPROF .PROGRAM.CNTL(SORTCNTL), opened in edit mode. 


File Edit Edit_Settings Menu Utilities Compilers Test Help 


EDIT ZPROF .PROGRAM.CNTL(SORTCNTL) - 01.00 Columns 00001 00072 
Command ===> Scroll ===> CSR 
KKEKKKK KKKKKKKEKKEKEKKKEKEKKKEKKRKEKKKKEKRKEEERE Top of Data KRKEKKKEKKKEKKEKKKEKKKEKKEKRKKERKERER 


000001 SORT FIELDS=(1,3,CH,A) 


KRKEKEKK KEEKKEKKKEKRKKEKRKEKRKEKERKERERERERE Bottom of Data KRKKKKKEKKKKKKKKKKKRKERKERERER 


Figure 3-12 Edit data set 


Observe the line numbers, the text area and the editor command line. Primary command 
line, line commands placed on the line numbers, and text overtype are three different 
ways in which you can modify the contents of the data set 


3.2.5 Using the online help 


Remember your private tutor, PFl-Help, when editing data sets. PFl in edit mode 
displays the entire editor tutorial (Figure 3-13). 
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TUTORIAL -------------------------- EDIT ----------------------------- TUTORIAL 
OPTION ===> 


Edit allows you to create or change source data. 


The following topics are presented in sequence, or may be selected by number: 
- General introduction 8 - Display modes (CAPS/HEX/NULLS) 


0 

1 - Types of data sets 9 - Tabbing (hardware/software/logical) 
2 - Edit entry panel 10 - Automatic recovery 

3 - SCLM edit entry panel 11 - Edit profiles 

4 - Member selection list 12 - Edit line commands 

5 - Display screen format 13 - Edit primary commands 

6 - Scrolling data 14 - Labels and line ranges 

7 - Sequence numbering 15 - Ending an edit session 


The following topics will be presented only if selected by number: 
16 - Edit models 
17 - Miscellaneous notes about edit 


Fl=Help F2=Split F3=Exit 
F7=PrvTopic F8=NxtTopic F9=Swap 


F4=Resize F5=Exhelp F6=Keyshelp 
F10=PrvPage F11=NxtPage F12=Cancel 


Figure 3-13 Edit Help Panel and Tutorial 


During the lab, you will edit a data set and use PFl-Help to explore the ‘Edit Line 
Commands’ and ‘Edit Primary Commands’ functions. Within the help function, select 
and review the ‘FIND/CHANGE/EXCLUDE commands’. This lab is important for 


developing further skills in this course. 


A subset of the line commands include: 


i 

Enter key 

i5 

d 

d5 

dd/dd 

r 

rr/rr 

c, then a or b 
c5, then a or b 
cc/cc, then a orb 
m, m5, mm/mm 
PF3 
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insert mode 

Press Enter without entering anything to escape insert mode 
obtain 5 input lines 

delete a line 

delete 5 lines 

delete a block of lines 

repeat a line 

repeat a block of lines 

copy a line after or before 

copy 5 lines after or before 

copy a block of lines after or before 
to move lines 

to save and exit 
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3.2.6 Customizing your ISPF settings 
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The command line for your ISPF session might appear at the bottom of the display, while 
your instructor’s ISPF command line might appear at the top. This is a personal 
preference, but traditional usage places it at the top of the panel. 


This is easy to change: 


1. 
2. 
3: 


Ik 


Go to the ISPF primary option menu. 
Select option 0 to display the Settings menu, as shown in Figure 3-14 on page 3-15. 
In the list of Options, remove the “/” on the line that says Command line at bottom. 
Use the Tab or New line key to move the cursor 


og/List Function keys Color 


s Environ 


Workstation 


Identifier 


Help 


ISPF Settings 


Command ===> 


Opt 
E 


~~ ~r lt ~nml 


Ter 
S 


T 


ions 

nter "/" to select option 
Command line at bottom 
Panel display CUA mode 
Long message in pop-up 
Tab to action bar choices 
Tab to point-and-shoot fiel 
Restore TEST/TRACE options 
Session Manager mode 
Jump from leader dots 
Edit PRINTDS Command 
Always show split line 
Enable EURO sign 


minal Characteristics 
creen format 2 1. Data 


erminal Type 3 1. 3277 
5. 3290A 
9. 3278KN 
13. 3278H0 
17. BE190 
21. DEU78A 
25. SW500 


Figure 3-14 ISPF settings 


ds 


2. Std 


2. 
6. 
. 3278AR 
. 32781S 
. 3278TH 
. DEU90A 


Print Graphics 
Family printer type 2 


Device name... . 
. 0 


Aspect ratio 


General 


Input field pad. . 
Command delimiter . 


3. Max 


3277A 
3278T 


3. 
Ts 
ll. 
153 
19. 
- SW116 


4. Part 


3278 

3278CF 
3278CY 
327812 
3278CU 


- 3278A 
- 3277KN 
12. 
16. 
20. 
24, 


3278HN 
BE163 
DEU78 
SW131 


While in this menu, you can change some other parameters that you will need later: 


> 


> 


Remove the “/” from Panel display CUA mode. 


Change the Zerminal Type to 4. This provides 3270 support for symbols used by the C 


language. 


Move the cursor to the Log/List option in the top line and press Enter. 


— Select 1 (Log Data set defaults). 
— Enter Process Option 2 (to delete the data set without printing). 
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— PF3 to exit. 
> Move the cursor to the Log/List option again. 
— Select 2 (List Data set defaults) 


— Enter Process Option 2 to delete the data set without printing. 


— PF3 to exit. 


> PF3 to exit to the primary menu. 


3.3 Adding a GUI to ISPF 


ISPF is a full panel application navigated by keyboard. You can, however, download and 
install a variety of ISPF graphical user interface (GUI) clients to include with a z/OS 
system. After installing the ISPF GUI client, it is possible to use the mouse. 


3-16 


Figure 3-15 on page 3-16 shows an example of an ISPF GUI. 
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« Jeg 
ISPF Primary Option Menu 

oO Settings Terminal and user parameters User ID . : PNEWTON 

i. View Display source data or listings Taine. .. .. & GWarios 

2 Edit Create or change source data Terminal : 3278 

3 Utilities Perform utility functions Screen. = AL 

4 Foreground Interactive language processing Language. : ENGLISH 

5 Batch Submit job for language processing Appl ID > PDF 

6 Command Enter TSO or Workstation commands TSO logon : IKJACCT 

7 Dialog Test |Perform dialog testing TSO prefix: PNEWTON 

8 IM Facility |Library administrator functions System ID : SCO4 

3: IBM Products /|IBM program development products M¥S acct. : ACCNT# 

10 SCLM SW Configuration Library Manager Release . : ISPF 5.2 


11 Workplace ISPF Object~“Action Workplace 


Enter K)to Terminate using log/’list defaults 


















Option ===> 
Fi-=Help F2=Split 
F3=Exit F?=Backward F8=Forward Fi0=Actions 





Figure 3-15 ISPF GUI 


The drop down entries at the top of the ISPF panels require placing the cursor on the drop 
down selection and pressing Enter. Moving the ISPF GUI client mouse pointer across the 
drop down selection will drop down the respective sub selections. Also available are 


Enter and PF key boxes. 
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3.4 Summary 


ISPF is a menu driven interface for user interaction with z/OS system. The ISPF 
environment is executed from native TSO. ISPF provides utilities, an editor and ISPF 
applications to the user. To the extent permitted by various security controls an ISPF user 
has full access to most z/OS system functions. 


TSO/ISPF has no equivalent of a simple word processor or spreadsheet program or 
modern e-mail interface. TSO/ISPF should be viewed as a system management interface 
and a development interface for traditional z/OS programming. 


Key terms in this chapter 


3270 emulator CLIST ISPF Hlogon 





Restructured SDSF Time Sharing user ID 
Extended Executor Option / Extensions 
(REXX) (TSO/E) 


3.5 Discussion questions 


1. Ifyou want more information about a specific ISPF panel or help with a user error, 
what should be your first action? 


2. Why is the ISPF command pfshow on/off useful? 


3. ISPF is a full screen interface with a full screen editor and TSO is a command line 
interface with only a line editor. The TSO line editor is rarely used. Can you think of 
a situation which require use of the TSO line editor? 


4. Can the IBM-provided panels of ISPF be customized? 
5. Is it possible to build local ISPF applications? 


3.6 Exercises 


The lab exercises in this chapter will help you develop skills in using TSO and ISPF. 
These skills are required for performing lab exercises in the remainder of this textbook. 


To perform the lab exercises, each student or team will require a TSO user ID and 
password (for assistance, see the instructor). 
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The lab exercises are intended to teach TSO and ISPF through trial and error, so mistakes 
are expected. Do not get frustrated. Instead, discuss the exercises with your classmates 
and work through them in teams, as needed. 


The exercises teach the following: 


“TSO logon and TSO commands” on page 3-18 
“Basic ISPF navigation” on page 3-18 

“ISPF editor” on page 3-19 

“What is SDSF?” on page 3-20 

“Optional exercise: paging concepts” on page 3-21. 


vvvvy 


3.6.1 TSO logon and TSO commands 


Establish a 3270 connection with z/OS using workstation 3270 emulator and log on to 
TSO with your user ID (yourid). From the TSO READY prompt (=x will exit out of ISPF), 
enter the following commands: 


PROFILE What is the prefix value? 
PROFILE NOPREFIX 
LISTC Display the list of catalog entries. Your 3270 emulator will have 


a PAI (attention) key. Find and send PA1 to the system to end the 
command output. 
Note: ‘***’ indicates full screen, Press Enter or PA1 


PROFILE PREFIX (yourid) 
LISTC What is displayed? 
ISPF 


3.6.2 Basic ISPF navigation 


3-18 


Starting from the ISPF Primary Option Menu, do the following: 
1. Select Utilities, then select Dslist from Utility Selection Panel 


2. Enter SYS1 on the Dsname Level input field and press Enter. What is displayed? Use 
PF8 to page down or forward, PF7 to page up or backward, PF10 to shift left and PF11 
to shift right. Exit with PF3 


3. Enter SYS1.PROCLIB on Dsname Level input field and press Enter. What is 
displayed? 


4. Enter ‘v’ in the command column (left of) SYS1.PROCLIB. This is a partitioned data 
set with numerous members. Place an ‘s’ to the left of any member to select the 
member for viewing. Press PF1. What specific help is provided? 
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. Enter =0 on the ISPF command or option line. What is the first option listed in this 


ISPF Settings Panel? Change your settings to place command line at bottom of panel. 
It is effective upon exit from settings panel. 


Tip: As you become more familiar with ISPF, you will learn the letters and numbers 
for some of the commonly used options. Preceding an option with the = key takes you 
directly to that option, bypassing the menus in between. 


You can also go directly to nested options with the = sign. For example, =P.3.4 takes 
you directly to a commonly-used data set utility menu. 


Enter PFSHOW OFF and then PFSHOW ON. What is the difference? How is this useful? 


Exit back to the ISPF Primary Option Menu. What value is used to select Utilities? 
Select Utilities 


In the Utilities Selection Panel, what value is used to select Dslist? Exit back to the 
ISPF Primary Option Menu. On the option line, enter Utilities selection value 
followed by a period then the Dslist selection value. What panel is displayed? 


Exit back to ISPF Primary Option Menu. Place the cursor on the ‘Status’ entry at the 
very top of panel and press Enter. Select ‘calendar’ value and press Enter, then select 
‘session’ value. What changed? 


3.6.3 ISPF editor 
Starting at the ISPF Primary Option Menu, do the following: 


1. 
2. 


Go to Dslist Utility Panel and enter yourid. JCL in Dsname Level field. 


Place ‘e’ (edit) to the left of yourid.JCL. Place ‘s’ (select) to the left of member 
EDITTEST. Enter PROFILE on the edit command line, observe the data is preceded by 
profile and message lines. Read the profile settings and messages, then enter RESET 
on the command line. What was the result? 


Enter any string of characters and the end of the first data line, then press Enter. On 
the command line, enter CAN (cancel). Again edit EDITTEST in the data set. Were your 
changes saved? 


Press PF2. The result is a second ISPF panel. What occurs when PF9 is entered 
repeatedly? 


Using PF9, switch to the ISPF Primary Option Menu, then press PF1 to display the 
ISPF Tutorial panel. 


From the ISPF Tutorial panel, select Edit, select Edit Line Commands, then select 
Basic Commands. Press Enter to scroll through the basic commands tutorial. As you 
do so, frequently switch (PF9) to the edit session and exercise the commands in 
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EDITTEST. Repeat this same scenario for Move/Copy Commands and Shifting 
Commands. 


7. From the ISPF Tutorial panel, select Edit, select Edit Primary Commands, then 
select FIND/CHANGE/EXCLUDE commands. Press Enter to scroll through the 
FIND/CHANGE/EXCLUDE commands tutorial. As you do so, frequently switch 
(PF9) to the edit session and exercise the commands in EDITTEST. 


8. Enter =X on ISPF help panel to end the second ISPF panel session. Save and exit the 
Edit Panel (PF3) to return to the ISPF Primary Option Menu. 


3.6.4 What is SDSF? 


3-20 


From the ISPF Primary Option Menu, locate and select System Display and Search 
Facility (SDSF), a utility that lets you look at output data sets. The ISPF Primary Option 
Menu typically includes more selections than those listed on first panel, with instructions 
on how to display the additional selections. 
1. Enter LOG then shift left (PF10), shift right (PF11), page up (PF7) and page 
down (PF8). Enter TOP, then BOTTOM on the command input line. Enter DOWN 
500 and UP 500 on the command input line. You will learn how to read this system 
log later. 


2. Observe the ‘SCROLL’ value to the far left on the command input line. 
Scroll ===> PAGE 
Tab to the ‘SCROLL’ value. The values for SCROLL can be: 
C-CSR cursor 
P-PAGE page 
H-HALF _half-page 
You will find the SCROLL value on many ISPF panels, including the editor. You can 
change this value by entering the first letter of the scroll mode over the first letter of 


the current value. Change the value to CSR, place the cursor on another line in the 
body of the system log, and press PF7. Did it place the line with the cursor at the top? 


3. Enter ST (status) on the SDSF command input line, then enter SET DISPLAY ON. 
Observe the values for Prefix, Dest, Owner, and Sysname. A value of ‘*’ is all. These 
values are used to filter information in the panel. Enter 


PREFIX * 
OWNER * 
DEST 


The result should be: 
PREFIX=* DEST=(ALL) OWNER=* 


4. Enter DA, to display all active. Enter ST to retrieve the status of all jobs in input, 
active and output queue. Once again, PF7 (page up), PF8 (page down), PF10 (shift 
left) and PF11 (shift right) 
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If you plan to continue with optional exercises, skip the following logoff step. 


5: 


Enter ‘=X’ to exit the ISPF environment. From TSO READY, enter LOGOFF to exit 
TSO. The sign-on screen is shown. You can close your 3270 session emulator now. 


3.6.5 Optional exercise: paging concepts 


You might want to refer to Chapter 2, “z/OS overview” during the following exercise. 


> 


Find out how much real memory is available on your system: 


— Goto SDSF 
— Enter the command ULOG 
— Enter /D M=STOR 


z/OS real storage is divided into frames of 4 kilobytes each, enough to hold a page. To 
maintain a reserve of available frames, z/OS pages out less frequently used frames. 
z/OS uses paging data sets on auxiliary storage to hold paged out frames temporarily. 
The Pageable Link Pack Area (PLPA) contains programs that can be paged out. 


— Enter /D ASM and /D ASM,PLPA 


¢ How many slots are allocated to hold paged out PLPA frames? 
¢« How many have been used? 

¢ What is the name of the paging data set? 

* On which DASD volume does it reside? 


z/OS can also page out common storage area. To see it, enter /D ASM, COMMON 
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3.7 Instructor notes 


3-22 


Refer to Figure 3-7 on page 8 "SORT panel" 


— Use this as a demonstration and go through the panels with the students. 


— In Example 3-3 on page 3-3 we must use TSO line commands, while we now go 
through the panels. 


— Use as SORTIN Input data sets ZPROF.AREA.CODES 
— Use as SYSIN Sort Control data sets ZPROF.SORT.CNTL 


Answers to 3.5, “Discussion questions” on page 3-17 


L; 
Bi 
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PF1 (HELP) 


pfshow off increases display area. The PF key settings can mask information written 
at the bottom of the display area. 


One possible situation is ISPF failure as a result of a change. The TSO line editor 
could be used to correct the error resulting in the ISPF failure. 


Yes. 
Yes. 
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Working with data sets 








Objective: In working with the z/OS operating system, you need to 
understand data sets, which contain programs and data. The data set 
characteristics of z/OS differ considerably from the files used in UNIX and PC 
systems. 


In this chapter, you will learn: 


What a data set is 

> Data set naming conventions and record formats 

> Some access methods for managing data and programs 
> How to create, delete and modify data sets 


Vv 
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4.1 What a data set is 


A data set is a collection of logically related data; it can be a source program, a library of 
macros, or a file of data records used by a processing program. Data records are the basic 
unit of information used by a processing program. 


In z/OS, there are two broad categories of data, system libraries (described in 17.3, “z/OS 
System Libraries” on page 17-8) and user application data (described in this chapter). 
There are many different data set types in z/OS, and many different methods to manage 
them. This chapter discusses three types. 


> Sequential data set 
Records are stored and retrieved in a sequential order. 
> Partitioned data set (PDS) and partitioned data set extended (PDSE) 


A PDS is a collection of sequential data sets, called members, each having a name. A 
directory is used to locate members in the partitioned data set. The directory consists 
of records that contain directory entries. There is one directory entry for each 
member. A partitioned data set is commonly referred to as a library. 


> VSAM 


An access method used to manage various user data types. 


Databases (such as IMS and DB2) are also used to more easily manage user data; these 
are described in later chapters. 


ISPF lets you create data sets and member names that follow the ISPF naming 
convention shown in “Naming conventions” on page 4-6. 


4.1.1 How data sets are stored 


4-2 


Disk data sets in a z/OS system are organized on disk volumes known as Direct Access 
Storage Device (DASD). The name of a data set must be unique on a volume. A data set 
can be located by device type, volume serial number, and data set name. This is unlike 
the file tree of a UNIX system. The basic z/OS file structure is not hierarchical. z/OS data 
sets have no equivalent to a path name. 


The disk and data set characteristics of zSeries hardware and software differ considerably 
from UNIX and PC systems. This chapter covers the access methods that z/OS uses to 
store and retrieve data, as well as discussing the storing of data on tape. It also covers 
general I/O subsystem design principles and discusses some devices, such as the 
following: 


> Direct Access Storage Device (DASD) is another name for a disk drive. 
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> A disk drive is also known as a disk volume, a disk pack, or a Head Disk Assembly 
(HDA). We use the term volume in this text except when discussing physical 
characteristics of devices. 

A disk drive contains cylinders. 

Cylinders contain tracks. 

Tracks contain data records and are in Count Key Data (CKD) format.! 

Data blocks are the units of recording on disk. 


vvvy 


4.1.2 Data set extents 


Space for a disk data set is assigned in extents. An extent is a contiguous number of disk 
drive tracks (or cylinders). Older types of data sets can have up to 15 extents. Newer 
types of data sets can have up to 128 or 255 extents. 


Data set extents are a fundamental part of z/OS operation and must be clearly understood. 
The reason for data set extents is performance.” Reading or writing contiguous tracks is 
faster than reading or writing tracks scattered over the disk, as might be the case if tracks 
were allocated dynamically. 


4.1.3 Record orientation 


Traditional z/OS data sets are record oriented. In normal usage, there are no byte stream 
files such as are found in PC and UNIX systems. (z/OS UNIX has byte stream files, and 
byte stream functions exist in other specialized areas. These are not considered to be 
traditional data sets.) 


In z/OS, there are no new line (NL) or carriage return and line feed (CR+LF) characters 
to denote the end of a record. Records are either fixed length or variable length in a given 
data set. When editing a data set with ISPF, for example, each line is a record. 


4.1.4 Tape data sets 


This chapter covers mainly disk data sets, but mainframe applications might also use tape 
data sets for many purposes. Mainframe tape drives have variable-length records 
(blocks). The maximum block size for routine programming methods is 65K bytes. 
Specialized programming can produce longer blocks. There are a number of tape drive 
products with different characteristics. 


' Current devices actually use Extended Count Key Data (ECKD) protocols, but we use CKD as a collective 
name in the text. 

2 A second reason is for integrity. Once a data set extent is created (and entered in the VTOC) a later system 
failure will not affect the integrity of the extent allocation. Dynamic allocation methods, such as used in PC 
operating systems, are more likely to lose recent disk usage information in the event of a failure. 
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4.2 Basic record formats 


4-4 


Traditional z/OS data sets have one of five record formats, as shown in Figure 4-1 on 
page 4-5. We must again stress the difference between a block and a record. In this 
discussion, a block is what is written on disk, while a record is a logical entity. The five 


formats are: 


F - Fixed 


FB - Fixed Blocked 


V - Variable 


VB - Variable Blocked 


U - Undefined 
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This means that one physical block on disk is one logical record 
and all the blocks/records are the same size. This format is 
seldom used. 


This means that several logical records are combined into one 
physical block. This can provide efficient space utilization and 
operation. This format is commonly used for fixed-length 
records. 


This format has one logical record as one physical block. The 
application is required to insert a four-byte Record Descriptor 
Word (RDW) at the beginning of the record. The RDW contains 
the length of the record plus the four bytes for the RDW. This 
format is seldom used. 


This format places several variable-length logical records (each 
with an RDW) in one physical block. The software must place 
an additional Block Descriptor Word (BDW) at the beginning 
of the block, containing the total length of the block. 


This format consists of variable-length physical records/blocks 
with no predefined structure. Although this format may appear 
attractive for many unusual applications, it is normally used 
only for executable modules. 
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block block block block 
F record record record record 
Fixed records. BLKSIZE = LRECL 
block block 
FB record | record | record record | record | record 
Fixed blocked records. BLKSIZE = n x LRECL 
block block block 
Ms record lp | record record 
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RDW 


Variable records. BLKSIZE >= LRECL (LRECL = 4 + data length) 
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block 
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VB t record 
BDW 


block 


Variable blocked records. BLKSIZ 


block 


block 


E>=4+nx LRECL 


block 








record 


record 








record 














record 








Undefined records. No defined internal structure for access method. 


Record Descriptor Word and Block Descriptor Word are each 4 bytes long. 








Figure 4-1 Basic record formats 


The terminology here is pervasive throughout z/OS literature. The key terms are: 


Block Size (BLKSIZE) is the physical block size written on the disk for F and FB 


> 


> 


records. For V, VB, and U records it is the maximum physical block size that can be 
used for the data set. 


Logical Record Size (LRECL) is the logical record size (F, FB) or the maximum 
allowed logical record size (V, VB) for the data set. Format U records have no 


LRECL. 


Record Format (RECFM) is F, FB, V, VB, or U as just described. 


These terms are known as data control block (DCB) characteristics, named for the 
control block where they may be defined in an assembly language program. The user is 
often expected to specify these parameters when creating a new data set. 
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4.3 Data set names 


The z/OS rules for all data set names are rather arbitrary but must be clearly understood. 
The rules include: 


> 


Data set names are UPPER CASE. In many cases they can be typed as lower case and 

a dialog manager program (such as ISPF) will change them to upper case. 

A data set name is a maximum of 44 characters, including internal periods. The 

characters may be alphabetic or numeric. They must begin with an alphabetic 

character. A few special characters are permitted, but it is better to avoid them. 

A data set can have an unqualified name: | through 8 alphanumeric or national 

characters. The first character must be alphabetic or national. For example, 

DSNAME=ALPHA is an unqualified data set name. 

A data set name is divided into qualifiers. These are a maximum of 8 bytes and are 

separated by periods. For example, P390Z.LIB.CNTL is a valid data set name with 

three qualifiers. 

The first qualifier is known as the high level qualifier (HLQ) and has implications for 

security controls and other functions. 

Other than the HLQ, the rest of the data set name is up to the user. There are usually 

no controls for this, although there are conventions about names. 

A library member (described later) has a name that is a maximum of 8 characters; 

these can be alphabetic or numeric. 

An individual library member, MARY, is named in this format: 
P390Z.LIB.CNTL(MARY) (assuming P390Z.LIB.CNTL is a library) 

In this case, the maximum name size is 54 characters: 44 for the data set name, 8 for 

the member name, and 2 for the parenthesis. 


4.3.1 Naming conventions 
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The HLQ for a user’s data sets is typically controlled by the security system. There are a 
number of conventions for the remainder of the name. These are conventions, not rules, 
but are widely used. They include the following: 


> 
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The letters LIB somewhere in the name indicate that the data set is a library. The 
letters PDS are a lesser-used alternative for this. 

The letters CNTL, JCL, or JOB somewhere in the name typically indicate the data set 
contains JCL (but might not be exclusively devoted to JCL.) 

The letters LOAD, LOADLIB, or LINKLIB in the name indicate that the data set 
contains executables. (A library with z/OS executable modules must be devoted 
solely to executable modules.) 

The letters PROC, PRC, or PROCLIB indicate a library of JCL procedures. These are 
described in 5.10, “JCL procedures (PROC)” on page 5-14. 

Various combinations are used to indicate source code for a specific language. For 
example, COBOL, ASM, FORTRAN, PLI, JAVA, C, or CPP. 

A portion of a data set name may indicate a specific project, such as PAYROLL. 
Using too many qualifiers is considered poor practice. For example, 
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P390A.A.B.C.D.E.F.G.H.I.J.K.L.M.N.0O.P.Q.R.S 
is a valid data set name (upper case, does not exceed 44 bytes, no special characters) 
but it is not very meaningful. A good practice is for a data set name to contain three 
or four qualifiers. 


4.3.2 Temporary data sets 


Some programs, such as compilers, use temporary data sets. A temporary data set is a 
data set that you create and delete within a job. When you define a temporary data set, 
you can code the DSNAME parameter or omit it; in either case, the system generates a 
qualified name for the temporary data set. 


When you use DSNAME for a temporary data set, code the name as two ampersands 
(&&) followed by a character string | to 8 characters in length, for example: 


//DDOUT DD DSNAME=&&PAYOUT1,SYSOUT=P 


DD statement DDOUT defines PAYOUT] as the last qualifier of the system-generated 
data set name for the sysout data set. This generates a data set name such as: 


userid. jobname. jobid.Ddsnumber.PAYOUT1. 


4.4 Access methods 


Two widely used formats for storing and retrieving data include VSAM and libraries. 
Following are brief discussions of each method. 


4.4.1 VSAM 


Virtual Storage Access Method (VSAM) is an access method that provides much more 
complex functions than other disk access methods. VSAM keeps disk records in a unique 
format that is not understandable by other access methods. VSAM can organize its data 
in several ways: 


> Key Sequence Data Set (KSDS). This is the most common use for VSAM. Each 
record has one or more key fields and a record can be retrieved (or inserted) by key 
value. This provides random access of data. Records are variable length. 


> Entry Sequence Data Set (ESDS). This form of VSAM is seldom used. It keeps 
records in sequential order. (QSAM is much more typically used for this type of data.) 


> Relative Record Data Set (RRDS). This VSAM format allows retrieval of records by 
number; record 1, record 2, and so forth. This provides random access and assumes 
the application program has a way to derive the desired record numbers. 
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> Linear Data Set (LDS). This 1s, in effect, a byte-stream data set and is the only form 
of a byte-stream data set in traditional MVS. A number of z/OS system functions use 
this format heavily but it is rarely used by application programs. 


There are several additional methods of accessing data in VSAM that are not listed here. 
Most application use of VSAM is for keyed data. 


VSAM is primarily for applications. It is not used for source programs, JCL, or 
executable modules. VSAM files cannot be routinely displayed or edited with ISPF. The 
AMS Utility is used to define VSAM catalogs, data spaces, clusters, files, and indexes. 


4.4.2 Libraries 


Partitioned data sets (PDS or PDSE) are commonly called libraries. They are data sets 
that contain members. 


Libraries are used for storing source programs, system and application control 
parameters, JCL, and executable modules. There are very few system data sets that are 
not libraries. The older library format (PDS) loses space every time a member is updated 
or added. It is necessary to compress the PDS to recover this space. 


The first part of a library is a directory. The directory contains the names of members and 
pointers to the members. Member names are listed alphabetically in the directory, but 
members themselves can appear in any order in the library. 


4.5 Finding your data 


z/OS has a number of components that help you find a data set, including VTOCs and 
catalogs. Following are brief discussions of VTOCs and catalogs. 


4.5.1 VTOCs 
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z/OS requires a particular format for disks, which is shown in Figure 4-2 on page 4-9. 
Record 1 on the first track of the first cylinder provides the label for the disk. It contains 
the 6-character volume serial number (volser) and a pointer to the Volume Table Of 
Contents (VTOC), which can be located anywhere on the disk. The VTOC contains the 
names of all the data sets on the disk volume and pointers to these data sets. A standard 
z/OS utility program, ICKDSF, is used to create the label and VTOC. 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter4 data sets.fm 





LABEL 
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Figure 4-2 Disk label, VTOC, extents 


When a disk volume is initialized with ICKDSF, the owner can specify the location and 
size of the VTOC. The size can be quite variable, ranging from a few tracks to perhaps 
100 tracks, depending on the expected use of the volume. More data sets on the disk 
volume require more space in the VTOC. 


The VTOC also has entries for all the free space on the volume. Allocating space for a 
data set (described later) causes system routines to examine the free space records, 
update them, and create a new VTOC entry. Data sets are always an integral number of 
tracks (or cylinders) and start at the beginning of a track (or cylinder). 


4.5.2 Catalog 


The catalog (collectively the master catalog and all the user catalogs) stores information 
based on data set names. This means that data set names must be unique. Both disk and 
tape data sets can be cataloged. 


z/OS must know three details to find a data set: 
> Data set name 


> Volume name 


> Unit (the volume device type, such as a 3390 disk or 3590 tape) 


You can specify all three values on the ISPF panels or in JCL. However, the unit device 
type and the volume are often not relevant to an end user or application program. A 
system catalog is used to store and retrieve UNIT and VOLUME location of a data set. In 
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its most basic form a catalog can provide the unit device type and volume name for any 
data set that is cataloged. A system catalog provides a simple look up function. With this 
facility the user need only provide a data set name. 


A z/OS system always has at least one master catalog. If a z/OS system has a single 
catalog, this catalog would be the master catalog and the location entries for all data sets 
would be stored in it. A single catalog, however, would be neither efficient nor flexible, 
so a typically z/OS system uses a master catalog and numerous user catalogs connected 
to it. 


A user catalog stores the name and location of a data set (dsn/volume/unit). The master 
catalog usually stores only a data set HLQ with the name of the user catalog, which 
contains the location of all data sets prefixed by this HLQ. The HLQ is called an alias. 


In Figure 4-3, the data set name of the master catalog is SYSTEM.MASTER. CATALOG. This 
master catalog stores the full data set name and location of all data sets with a SYS1 
prefix such as SYS1.A1. Two HLQ (alias) entries were defined to the master catalog, 
IBMUSER and USER. The statement that defined that IBMUSER included the data set 
name of the user catalog containing all the fully qualified IBMUSER data sets with their 
respective location. The same is true for USER HLQ (alias). 
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Figure 4-3 Catalog concept 


When SYS1.A1 is requested, the master catalog returns the location information, 
volume(WRK001) and unit(3390), to the requestor. When IBMUSER.A1 is requested, 
the master catalog redirects the request to USERCAT.IBM, then USERCAT.IBM returns 
the location information to the requestor. 


As a general rule, all user data sets in a z/OS installation are cataloged. Uncataloged data 


sets are rarely needed and their use is often related to recovery problems or installation of 
new software. Data sets created through ISPF are automatically cataloged. 


4.6 Summary 


A data set is a collection of logically related data; it can be a source program, a library of 
macros, or a file of data records used by a processing program. Data records are the basic 
unit of information used by a processing program. 
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z/OS data sets are allocated in contiguous extents on a disk to enhance performance. 
Users must define the amount of space to be allocated for a data set (before it is used). A 
data set may occupy more than one extent and extents may be added dynamically. 


Almost all z/OS data processing is record-oriented. Byte stream files are not present in 
traditional processing, although they are a standard part of z/OS UNIX. z/OS records 
(and physical blocks) are in one of several well-defined formats. Most data sets have 
DCB attributes that include the record format (RECFM—F, FB, V, VB, U), the maximum 
logical record length (LRECL), and the maximum block size (BLKSIZE). 


z/OS data sets have names with a maximum of 44 uppercase characters, divided by 
periods into qualifiers with a maximum of 8 bytes per qualifier name. The high-level 
qualifier (HLQ) may be fixed by system security controls, but the rest of a data set name 
is assigned by the user. A number of conventions exist for these names. 


An existing disk data set can be located when the data set name, volume and device type 
are known. These requirements can be shortened to knowing only the data set name if the 
data set is cataloged. The system catalog is a single logical function, although its data 
may be spread across the master catalog and many user catalogs. In practice, almost all 
disk data sets are cataloged. One side effect of this is that all (cataloged) data sets must 
have unique names. 


Virtual Storage Access Method (VSAM) is an access method that provides much more 
complex functions than other disk access methods. VSAM is primarily for applications 
and cannot be edited via ISPF. 


z/OS libraries are known as partitioned data sets (PDS or PDSE) and contain members. 
Source programs, system and application control parameters, JCL, and executable 
modules are almost always contained in libraries. 














Key terms in this chapter 
BLKSIZE (block size) __ data set HLQ 

library LRECL (record length) 
member PDS and PDSE RECFM (record format) 
VSAM Master catalog, User VTOC 

catalog 











4.7 Discussion questions 
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1. What is a data set? What types of data sets are used on z/OS? 
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2. Why the continued use of a PDS after all these years of newer data designs? 
3. Do application programs use libraries? Why or why not? 


4. What determines the largest file a traditional UNIX system can use? Is there an 
equivalent limit for z/OS? 


5. Do you see any patterns in temporary data set names? 


6. The data set information provided by ISPF 3.4 is helpful. Why not display all the 
information on the basic data set list panel? 


7. We created a source library in one of the exercises and specified fixed-length 80-byte 
records. Why? 


4.8 Exercises and demonstrations 


> Inform yourself about data set characteristics. 
> Create a new data set. 
> Work with library members. 


4.8.1 ISPF Option 3.4 - data set space and characteristics 


One of the most useful panels is 3.4. This terminology means, starting from the primary 
menu, select option 3 (Utilities) and then option 4 (Dslist, for data set list). This sequence 
can be abbreviated by entering 3.4 in the primary menu, or =3.4 from any panel. The 
3.4 functions were added later to ISPF and duplicated many existing functions. However, 
the operation of the 3.4 panels are more convenient than the older panels and many ISPF 
users work almost exclusively within the 3.4 panels. We cover some of the 3.4 functions 
in different exercises. Be careful with 3.4 options until you have a reasonable idea about 
what they do. 


**** Tn the following exercises, WORKO2 is a sample volume name. The instructor will 
provide a volume name to be substituted. 


What data sets are on this volume? How many different data set types are on the volume? 
What are the DCB characteristics of a student CNTL file? To answer these questions, do 
the following: 


1. Inthe 3.4 panel, enter WORKO2 in the Volume Serial field. Do not enter anything on the 
Option==> line or in the Dsname Level field. 


2. Use PF8 and PF7 to scroll through the data set list that is produced. 


3. Use PF11 and PF10 to scroll sideways to display more information. (This is not really 
scrolling in this case; the additional information is obtained only when PF11 or PF10 
are used.) 
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The first PF11 display provides tracks, percent used, XT, and device type. The XT 
value is the number of extents used to obtain the total tracks shown. The ISPF utility 
functions can determine the amount of space actually used for some data sets and this 
is shown as a percentage when possible. 


The next PF11 display shows the DCB characteristics: DSORG, RECFM, LRECL, 
and BLKSIZE. 


PS Indicates a sequential data set (QSAM, BSAM) 

PO Is a partitioned data set 

VS Is VSAM 

blank Indicates it is an unknown organization (or that no data exists). 


RECFM, LRECL, and BLKSIZE should be familiar. In some cases (usually when a 
standard access method is not used or when no data has been written) these 
parameters cannot be determined. VSAM data sets have no direct equivalent for these 
parameters and are shown as question marks. 


Look at another volume for which a larger range of characteristics can be observed. The 
instructor can supply volume serial numbers. 


4.8.2 Creating a new data set 
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ISP 


F provides a convenient method to allocate new data sets. Each student needs to 


create a new library intended for program source data. The new data sets should be 
placed on the WORKO2 volume and should be named yourid.LIB.SOURCE (where 
yourid is your student user ID). From experience we know that 10 tracks of primary 
space and 5 tracks for secondary extents is sufficient, and that 10 directory blocks is 
sufficient. Furthermore, we know we want to store 80-byte fixed-length records in the 


libr 
1. 


2 
3, 
4 
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ary. We can do this as follows: 


Start at the ISPF primary menu. 


. Go to option 3.2 - or go to option 3 (Utilities) and then go to option 2 (Data Set). 


Type the letter A in the Option ==> field, but do not press Enter yet. 


. Type the name of the new data set in the Data Set Name field, but do not press Enter 


yet. The name can be with single quotes (for example, ‘yourid.LIB.SOURCE’) or 
without quotes (LIB.SOURCE) so that TSO/ISPF automatically uses the current TSO 
user ID as the HLQ. 


Enter WORKO2 in the Volume Serial field and press Enter. 
Complete the indicated fields (and then press Enter): 


— Space Units = TRKS 

— Primary quantity = 10 
— Secondary quantity = 5 
— Directory blocks = 10 
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— Record format = FB 

— Record length = 80 

— Block size=0 (this tells z/OS to select an optimum value) 
— Data set type = PDS 


This should allocate a new PDS on WORKO2. Check the upper right corner, where the 
following message appears: 


Menu RefList Utilities Help 


Data Set Utility Data set allocated 
Option ===> 


A Allocate new data set C Catalog data set 


cece 


4.8.3 Copy source library 


A number of source programs are needed for exercises in 
ZPROF.ZSCHOLAR.LIB.SOURCE on WORKO2. There are several ways to copy data sets 
(including libraries). We can use the following: 


1. Go to ISPF option 3.3 (Utilities, Move/Copy). 
2. On the first panel: 


— Type C in the Option==> field. 

— Type ‘ZPROF.ZSCHOLAR.LIB.SOURCE’ in the Data Set Name field. The single 
quotes are needed in this case. 

— The Volume Serial is not needed because the data set is cataloged. 

— Press Enter. 


3. On the second panel: 
— Type ‘yourid.LIB.SOURCE’ in the Data Set Name field and press Enter. 
4. This should produce a panel listing all the members in the input library: 
— Type S before every member name and then press Enter. 
This copies all the indicated members from the source library to the target library. We 
could have specified ‘ZPROF.ZSCHOLAR.LIB.SOURCE(*)’ for the input data set; this 


would automatically copy all the members. This is one of the few cases where wild cards 
are used with z/OS data set names. 


4.8.4 Working with data set members 


There are several ways to add a new member to a library. We want to add a member 
named TEST2 to your library that we previously edited: 


1. From the ISPF primary menu, use option 2. 
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2. Enter the name of your library without specifying a member name, for example 
yourid.JCcL. 


3. This provides a list of member names already in the library. 
4. Verify that member EDITTEST has the same contents you used earlier: 
— Ifnecessary, scroll so you can see member name EDITTEST. 
— Move the cursor to the left of this line. 
— Type S and press the 3270 Enter key. 
— Look at your earlier work to assure yourself it is unchanged. 


— Press PF3 to exit (“back out of’) member EDITTEST. You will see the library 
member name list again. 


5. Enter S TEST2 in the command line at the top of the screen and press 3270 Enter. 
(S TEST2 can be read as “select TEST2.”’) This creates member TEST2 and places 
the screen in input mode. 


6. Enter a few lines of anything, using the commands and functions we discussed earlier. 
7. Press PF3 to save TEST2 and exit from it. 
8. Press PF3 again to exit from the ISPF Edit function. 


Hereafter we will simply say “Enter xxx” when editing something or using other ISPF 
functions. This means (1) type xxx, and (2) press the 3270 Enter key. The New Line key 
(which has Enter printed on it) is used only to position the cursor on the screen. 


Tip: The 3270 Enter key and the PC Enter key can be confusing. Most 3270 emulators 
permit the user to assign these functions to any key on the keyboard, and we assume 
that the 3270 Enter function is assigned to the right-hand Ctrl key. Some zSeries users 
prefer to have the large PC Enter key perform the 3270 Enter function and have 
Shift-Enter (and/or perhaps the numeric Enter key) perform the 3270 New Line 
function. 


4.8.5 More ISPF 3.4 usage 
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Go to the ISPF 3.4 panel. Enter yourid in the Dsname Level field and press Enter. This 
should list all the cataloged data sets in the system with the indicated HLQ. An 
alternative is to leave the Dsname Level field blank and enter WORKO2 in the Volume 
Serial field; this lists all the data sets on the indicated volume. (If both fields are used, the 
list will contain only the cataloged data sets with a matching HLQ that appear on the 
specified volume.) 


A number of functions can be invoked by entering the appropriate letter before a data set 
name. For example: 
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Position the cursor before one of the data set names and press PF1 (Help). 


The Help panel lists all the line commands that can be used from the data set name list of 
the 2.4 panel. Do not experiment with these without understanding their functions. Not 
all of these functions are relevant to this class. The relevant commands are: 


Edit the data set 

Browse the data set 

Delete the data set 

Rename the data set 

Compress a PDS library to recover lost space 
Catalog the data set 

Uncatalog the data set 


GANA DUE 


When a member list is displayed (as when a library is edited or browsed) several line 
commands are available: 


Ss Select this member for editing or browsing 
R Rename the member 
D Delete the member 


4.8.6 Partial catalog search and online help (optional exercise) 


The ISPF 3.4 option can be used for catalog searches on partial names. Use PF-1 Help to 
learn more about this important function, as follows: 


1. Select option 3.4. 


2. Press PF1 for help and select Display a data set list. Press Enter to scroll through the 
information panels. 


3. Then select Specifying the DSNAME LEVEL. Press Enter to scroll through the 
information panels. 


4. Press PF3 to exit from the Help function. 


Notice that the 3.4 DSNAME LEVEL field does not use quotes and the current TSO/E 
user ID is not automatically used as a prefix for names in this field. This is one of the few 
exceptions to the general rule for specifying data set names in TSO. 
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4.9 Instructor notes 
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Chapter Overview 
> Describe the overall data storage process; 


a. Tape is used for sequentially organized files. 


b. DASD provides direct, sequential or indexed fields. Every DADS device has a 
VTOC to list contents of that DASD physical device (like books’ TOC). 


> Two major categories - user data and system data. 
a. System library structure contents - CRITICAL - described later 
b. User data - described in this chapter. 


Need a discussion of data hierarchy and associated access methods. E.g.: 
1. Individual data elements, or fields stored in a single logical record. 


2. Logical records are organized into files. Multiple logical records are stored in 
physical blocks on a DASD or tape. Application programming must do Read/Write of 
physical files and then deblock. User manages physical space and when the logical 
file expands to outgrow the allocated physical space, must explicitly request more. 
Similarly, user must reclaim any unneeded space. User appl gets access to entire 
logical and physical record - problem when new data elements or records must be 
added - insertion problem. 


3. Files can be accessed sequentially (describe), directly, or by using an index. 


4. To simplify the users’ application programming and space management tasks, IBM 
provides a higher level of space and file management, (VSAM). User allocates a 
block of DASD physical storage, and specifies the user application files that can be 
saved in this space. VSAM automatically reclaims unneeded space, allocates 
available empty space to growing files, inserts logical records in correct sequence, 
etc. VSAM has catalogs to control the files and space. VSAM has three basic access 
methods, corresponding to the way logical files are stored and retrieved (sequential - 
ESDS, direct - RRDS, indexed - KSDS). VSAM has a utility (AMS) to define, 
allocate & manage space, files, etc. An application only needs to request the logical 
record, VSAM does physical blocking and deblocking from the physical record. User 
appl gets the entire logical record, and must select individual fields. Potential security 
and confidentiality exposure. 


5. The highest level of logical and physical data element access is by using a DBMS 
(IMS or DB2). User only requests the required data element, the DBMS manages its 
location; uses VSAM access methods; data confidentiality and protection (can 
hide/control access of fields). DBMS is covered in Part 3 of this book. 
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Refer to 4.1.2, “Data set extents” on page 4-3 


Data set extent size and the number of extents affect performance and function in the 
following ways: 


> During a sequential database scan, excessively small extents can degrade 
performance. 


> Ifthe channels are fast, the performance impact of sequentially moving from one 
extent to another is greater. 


As a general guideline, the extent size is more important to performance than the number 
of extents. Recommendation should be to maintain extent sizes that are large enough to 
avoid excessively frequent extent moving during scans. 


Source: 


http://publib.boulder.ibm.com/infocenter/dzichelp/index.jsp?topic=/com.ibm.db2. 
doc.admin_8.1.0/bjndmstr538.htm 


A data set is typically created using job control language (JCL). This is described in 
detail in Appendix 5, “Batch processing, JCL, and Job Management with JES”. As an 
example, we might use a JCL statement to create a data set with 1000 tracks. When 
processing this JCL, z/OS inspects the free space information on the disk by checking the 
volume table of contents (VTOC). If 1000 tracks are available as a single extent 
(contiguous space), this space is allocated to the new data set and subtracted from the free 
space. If 1000 tracks are not available as contiguous space, z/OS attempts to allocate two 
extents (in different areas of the disk) for a total of 1000 tracks. z/OS continues this 
process, if necessary, up to five extents. If it is unable to find the 1000 tracks in five 
extents, then the allocation fails and the user receives an error message. The disk might 
not have 1000 tracks free, or the free space may be too fragmented. (There is a utility 
program to defragment disks, but it is seldom needed.) 


The JCL statements can specify secondary allocation for a data set. This causes z/OS to 
dynamically allocate additional extents (up to a total of 15 for traditional types of data 
sets) if the application fills the originally allocated extents. 


When allocating extents, the user must estimate the amount of space needed for a new 
data set. Sometimes this is easy, sometimes it is very difficult. In basic operation, the 
extent space allocated for a data set remains the same after the data set is written. For 
example, we might have allocated 1000 tracks for a data set but the application wrote 
only 50 tracks. The 1000 tracks remain allocated to the data set and the space is wasted. 
We might run the application again, using the same output data set, and use 900 tracks the 
next time. The space for the data set remains allocated until the data set is deleted from 
the VTOC. 
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There are JCL options to release unused space when an output data set is closed. 
However, this can lead to fragmentation of the free space on the disk volume and is not 
well suited if the data set might be rewritten many times with different amounts of data. 


Estimating the space required for a new data set is one of the less pleasant tasks for a 
z/OS user. If a data set is too small and the space allocation is much too large, a large 
amount of disk space may be wasted. The requirement to allocate space for a data set 
before it is created is often a stumbling block for new z/OS users, but it becomes much 
easier with a little experience. 


The concept of preallocated disk space, in contiguous extents, is one of many reminders 
of the origins and basic nature of z/OS. The system is designed for production operation 
of batch (or interactive subsystem) applications. The preallocated data set extents provide 
the best performance (and data integrity) in a production environment. In practice, for a 
production environment the necessary allocations are determined once and then seldom 
changed. 


Refer to 4.1.3, “Record orientation” on page 4-3 


Programs read or write records, starting on record boundaries. A program can read a data 
set starting at record 1000, but it cannot read a data set starting at byte 1000 from the 
beginning unless that corresponds to the beginning of a record.> A read or write operation 
always starts at the beginning of a record. Every read or write operation specifies a data 
length. (This length might be explicit or implied in various ways, but is always present.) 


For output operations, the data length specified (assuming it is within a valid range) 
corresponds to the record size written. Input operations have more conditions: 


> Ifaread operation asks for 1000 bytes, but the next record is 600 bytes, then only 600 
bytes are returned. If the records are variable size, the program will probably ask for 
the maximum possible size and then determine the size actually read. 


> Ifaread operation asks for 1000 bytes, but the next record is 1500 bytes, then 1000 
bytes are returned and the remaining 500 bytes are skipped. (A program code 
indicates that the record was longer than expected.) The next read operation 
(assuming a normal sequential data set) will read the next record and the skipped 500 
bytes are ignored. 


A read operation will return the requested number of bytes or the complete record, 
whichever is shorter. The application program can determine the actual number of bytes 
in the record just read. This facility of z/OS prevents the buffer overflow problem that 
occurs in other operating systems. It is an example of z/OS system integrity. 


3 This could be done with additional programming, of course, but we are discussing normal, typical, routine 
programming and usage here. 
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Refer to 4.2, “Basic record formats” on page 4-4 


These five formats are usually noted as F, FB, V, VB, and U record formats (RECFM). 
Most JCL, parameter files, source code, and some application data are in FB format. 
Most sequential application data is in VB format. The most common form of executable 
modules is in U format. The RDW in a variable-length record must be placed there by the 
application. Exactly how this is done depends on the language used. In COBOL, for 
example, it is done automatically by one of the language library routines. The BDW ina 
VB data set is usually placed there by a system library routine (an access method). 


The selection of fixed or variable length records depends on the nature of the application, 
and is usually decided by the application designer or programmer. The logical record 
length also depends on the nature of the application. For example, the system often 
expects JCL to be in 80-byte records. These could be blocked or unblocked. 


The blocksize for FB or VB records is normally not dependent on the application, and is 
normally transparent to the application program. Instead it is usually selected for 
optimum performance and disk utilization. It is common, for example, to select a 
blocksize that is half of a track size. This provides efficient hardware and system 
operation. 


There are many details, exceptions, and guidelines for using these DCB parameters that 
are not covered here. A few especially important details include: 


The BLKSIZE of an FB data set must be an even multiple of the LRECL. 

The LRECL ofa V or VB data set must include the four bytes for the RDW. 

The BLKSIZE for a VB data set must include the four bytes for the BDW. 

Very small block sizes are highly impractical. Sizes less than about 20 bytes may not 
work correctly. 

> Very small record sizes are also highly impractical. Resist the temptation to create a 
pseudo-byte-stream file by using LRECL=1. 


vvvy 


Refer to 4.3, “Data set names” on page 4-6 


A generation data group (GDG) is a collection of historically related non-VSAM data 
sets that are arranged in chronological order. Each data set is called a generation data set 
and is historically related to the others in the group. 


Refer to 4.4, “Access methods” on page 4-7 

It is possible to write an application using channel command words to directly control 
channels, control units, and I/O devices. Doing this would be very unusual and only 
when required for very special purposes; for example, when a high-level language (HLL) 
does not provide a specific function. I/O programming at this level is tedious at best and 
involves a great deal of special case programming and exception handling. It is much 
better to use system-provided I/O routines for many reasons, including the following: 


> The system-provided routines are highly efficient. Writing efficient programs at the 
channel-programming level is a nontrivial task. 
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Vv 


The provided routines are well tested and have been used for decades. 

The provided routines are well documented. 

Using the system-provided routines allows a programmer to concentrate on 
application code instead of detailed I/O coding. 

The access method can provide a degree of device independence; that is, the access 
method code automatically adapts itself to the device being used. 


The system-provided I/O routines are known as access methods. Traditional MVS I/O 
connectivity for disks is explained in “Early system design” on page 22-3. Once the I/O 
blocks are on disk, the user may wish to access them in several ways. This led to the 
name access methods. Different access methods accessed disk records in different ways. 
These differences include: 


> 


Automatically blocking (output) or unblocking (input) of logical records. Some 
access methods can simply deliver disk blocks and leave any blocking or unblocking 
to the application program. Other access methods can block or unblock fixed and 
variable length records, such that the application program deals only with logical 
records. 

Sequential or random access. Some access methods deliver blocks or logical records 
sequentially. Other access methods allow random or direct access to specific blocks 
or records without sequential processing. 

Management of parallel I/O and processing. Some access methods cause an 
application program to be suspended until the requested I/O operation is complete (or 
until the I/O record is moved to an access method buffer), while others allow the 
application program to manage such program suspensions. 

Buffering. Some access methods provide extensive read-ahead or write-behind 
buffering, while other access methods provide no buffering at all. Well-designed 
buffering is critical for best sequential data set performance. 


Some access methods have been obsoleted and a few new ones have appeared since 
OS/360 was first introduced. Access methods that have been used include: 


QSAM Queued Sequential Access Method (Heavily used) 
BSAM Basic Sequential Access Method (For special cases) 
BDAM Basic Direct Access Method (Becoming obsolete) 
BPAM Basic Partitioned Access Method (For libraries) 

VSAM Virtual Sequential Access Method (More complex) 
VTAM Virtual Telecommunications Access Method (Terminals) 
BTAM Basic Telecommunications Access Method (Obsolete) 
TCAM Telecommunications Access Method (Obsolete) 
QISAM Queued Index Sequential Access Method (Obsolete) 
BISAM Basic Index Sequential Access Method (Obsolete) 
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EXCP Execute Channel Program (Not really an access method) 
TCP/IP Not a traditional access method 


These can be quickly summarized: 


> QSAM is used for routine sequential I/O with disks and tapes. (It could also be used 


with card and printer devices if any of these devices are directly attached to an 
application.) QSAM can also be used with members of libraries. 


> VSAM is mostly used for keyed or indexed access, in which a record is located by a 


key field. It is not technically a data base, but might be said to exist halfway between 
more routine access methods and formal data base products. (The primary IBM data 
base product, DB2, uses VSAM data sets internally.) 


Excluding database software, discussed in Appendix 14, “Overview of DB2 on z/OS”, 
most existing z/OS applications use QSAM and VSAM for data access. 


> 


BPAM is used to access libraries. Within a library each member can be processed 
with QSAM or BSAM. 


BSAM is used, usually by assembly language programs, when special data block 
handling is needed. 


BDAM provides direct access to a disk block. Many older applications use it, but 
newer applications use VSAM instead. It is slowly becoming obsolete. 

VTAM, TCAM, and BTAM deal with terminal connections and are seldom directly 
used by application programs. TCAM and BTAM are obsolete. Some TCP/IP 
connections (such as TN3270) work in conjunction with VTAM. 

QISAM and BISAM are obsolete and have been replaced with VSAM. 


EXCP is not really an access method. It is an interface for an application program that 
provides its own channel control programs; it does not involve any access method. 


Table 4-1 Access method comparisons 


Automatic Sequentialor | Automatic Automatic 
Block/Unblock | Random Buffering Suspension 





QSAM yes sequential yes yes 





BSAM no sequential no no 





BDAM no random no no 





BPAM (library) no N/A no no 





EXCP no N/A no no 





VSAM random & seq yes (usually) 

















ISAMs (not used) random yes &no 
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4-24 


The access methods are often used transparently. For example, when ISPF accesses a 
member in a library, it uses BPAM to address the member and then uses QSAM to read or 
write the member. 


A programmer writing in assembler language uses access methods directly. A 
programmer writing in a higher-level language uses access methods indirectly, working 
through language facilities and the language library. 


Caches and buffers 


The concept of a cache in PC and UNIX systems involves system-owned memory where 
data from any files being used via the normal library I/O routines can temporarily reside. 
Data in output files is written at the convenience of the operating system, although the 
application can force data to be written from the cache. Such caches are important for 
performance in these systems. Key elements of these caches include: 


> The cache is, in a sense, a global area and is not tied to a particular application or user. 

> Data from many files exists in the cache. 

> Output data may be held in the cache for a variable amount of time, until the 
operating system decides to write it to disk. Any of several factors can trigger the 
writing. 

> Application programs have no control over the usage of the cache, assuming they are 
using common library I/O routines. 


Traditional z/OS methods of I/O do not use caches. (Disk and tape hardware may contain 
internal caches, but these are not seen by the software.) The UNIX System Services 
interfaces of z/OS do use such caches; this is described in a later chapter. 


The z/OS buffer concept is different and depends on the access method used. Some 
access methods provide no buffering and I/O is directly into/from the application work 
areas. QSAM provides the best implementation of buffering. When a file is opened for 
use with QSAM, the open routines automatically obtain buffer areas in the application’s 
private area of the address space. A buffer is normally the same size as the BLKSIZE for 
the data set. 


Buffers are designed to increase the efficiency of the I/O process by providing an entire 
physical block of records to be read or written all at once. The access method can process 
this buffer with a single read or write instruction, transparent to the application code. 


These buffers are associated with the data set being opened; they are not shared among 
multiple data sets. If several data sets are opened for use with QSAM then different 
buffer areas are obtained for each data set. Buffers are primed when a data set is opened 
for input. Output buffers are flushed when an output data set is closed. The application, 
through JCL or other methods, can specify the number of buffers to obtain. 


Summarized the different elements of cache and buffer storage as used on mainframes 
versus UNIX and personal computing systems. 
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Table 4-2 


In the tape/disk controller Global area 





Refer to 4.4.1, “VSAM” on page 4-7 
Browse and Update VSAM data sets is supported by DITTO, an IBM-licensed program 
installed under ISPF. 


Programming for VSAM tends to be simple in high-level languages and considerably 
more complex in assembly language. The high-level language uses, in essence, a 
single-thread access with automatic suspension of the application while VSAM works. 
The assembly language user can control multiple concurrent VSAM requests and 
determine when to wait for completion of an I/O request. 


VSAM works with a logical data area known as a Control Interval (CI) that is 
diagrammed in Figure 4-4. The default CI size is 4K bytes, but it can be up to 32K bytes. 
The CI contains data records, unused space, Record Descriptor Fields (RDF), and a Cl 


























Descriptor Field. 
R|R [R/C 
Rl R2 R3 Free space in CI pip/iDIp 
F|F JF /F 
Record Descriptor Fields Lr 











Figure 4-4 Simple VSAM control interval 


A control interval may be constructed from smaller disk blocks, but this level of detail is 
internal to VSAM. Multiple control intervals are placed in a Control Area (CA). A 
VSAM data set consists of control areas and index records. One form if index record is 
the sequence set, which is the lowest-level indexes pointing to control intervals. 


Typical use of VSAM permits an application to insert new records in a data set. The 
structure that permits this is interesting: 


> Records in a control interval are in ascending order, based on the primary key of the 
records. A given control interval contains all the data set records between the record 
with the lowest key and the record with the highest key in that control interval. 

> The RDF fields contain the length of each logical record and the offset (into the CI) 
for that record. The CIDF contains information about the free space in the CI. 
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> When the VSAM data set is first allocated, the user can specify the amount of free 
space to leave in each control interval. A percentage of free (empty) control intervals 
in each control area can also be specified. 

> When a new record is to be inserted (in key order) VSAM uses the key records to 
determine the control interval holding records in the appropriate key range. 

> If the control interval has sufficient free space the logical records in the control 
interval are shifted (of necessary) and the new record is inserted. 

> Ifthe control interval does not have sufficient space, a control interval split occurs. A 
free control interval (in the same control area) is located and approximately half the 
records in the data control interval are moved to the empty control interval and the 
new record is inserted into the original control interval. 

> Index pointers are adjusted as necessary to include the newly used control interval. 

> Ifno free control interval is found in the control area then a control area split occurs. 
The follows roughly the same logic as a control interval split. If a free control area 
does not exist (or cannot be added to the data set) they data insert fails and the 
application probably fails. 


There are many details of VSAM processing that are not included in this brief 
description. All this processing is handled transparently by VSAM. The application 
program merely retrieves, updates, deletes or adds records based on key values. 


VSAM data is always variable length and records are automatically blocked in control 
intervals. The RECFM attributes (F, FB, V, VB, U) do not apply to VSAM, nor does the 
BLKSIZE attribute. 


The default CI size for VSAM is 4K bytes. A 3390 volume holds 12 of these records on a 
track. With 15 tracks per cylinder, there are 180 of these CIs per cylinder. A typical 
control area size is one cylinder. The Access Method Services (AMS) utility provides the 
user interface to defining and deleting VSAM entities (catalogs, data spaces, and clusters 
of indexes and data). 


Refer to 4.5.2, “Catalog” on page 4-9 


The define statements below are used to place IBMUSER and USER alias names in the 
master catalog with the name of the user catalog that will store the fully qualified data set 
names and location information. 


DEFINE ALIAS ( NAME ( IBMUSER ) RELATE ( USERCAT.IBM ) ) 
DEFINE ALIAS ( NAME ( USER ) RELATE ( USERCAT.COMPANY ) ) 


If IBMUSER.A1 is cataloged, then a JCL statement to allocate it to the job would be: 
//INPUT DD DSN=IBMUSER.A1,DISP=SHR 


If IBMUSER.A1 is uncataloged, then a JCL statement to allocate it to the job would be: 
//INPUT DD DSN=IBMUSER.A1,DISP=SHR, VOL=SER=WRKOO1,UNIT=3390 
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2D 


Batch processing, JCL, and 
Job Management with JES 








Objective: As a worker in the mainframe environment, you need to understand the 
ways in which the system processes your company’s core applications, such as 
payroll. Such workloads are usually performed through batch processing, which 
involves executing one or more batch jobs in a sequential flow. 


Also, you need to know JCL, the language that tells z/OS which resources will be 
needed to process a batch job or start a system task. 


Lastly, you need to understand how the job entry subsystem (JES) enables batch 
processing. JES helps z/OS receive jobs, schedule them for processing, and determine 
how job output is processed. 


In this chapter, you will learn: 


> An overview of batch processing and how work is initiated and managed in the 
system 

> How JCL works with the system, an overview of JCL coding techniques, and a 
few of the more important statements and keywords 

> How JES governs the flow of work through the z/OS system 
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5.1 What batch processing is 
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There is no direct counterpart to z/OS batch processing in PC or UNIX systems. Batch 
jobs are for those frequently used programs that can be executed with minimal human 
interaction. They are typically executed at a scheduled time or on an as-needed basis. 
Perhaps the closest comparison is with processes run by an AT or CRON command in 
UNIX, although the differences are significant. A z/OS batch job consists of programs 
that run in environments described by the job control language (JCL). After the JCL is 
submitted to the system, there is normally no further human interaction with the job until 
it is complete. 


The basic elements of batch processing are shown in Figure 5-1. The jobs in this diagram 
represent JCL and perhaps data intermixed with the JCL. Source code input for a 
compiler is a typical example of data (the source statements) that might be intermixed 
with JCL. Another example is an accounting job that prepares the weekly payroll for 
different divisions of a firm (presumably, the payroll application program is the same for 
all divisions, but the input and master summary files may differ). The diagram represents 
the jobs as punched cards (using the conventional symbol for punched cards) although 
real punched card input is very rare now. Typically, a job consists of card images (80-byte 
fixed-length records) in a member in a partitioned data set. 





JCL Processing 


JES 
Initiator 





- Allocation 
- Execution 
- Cleanup 


Submit 








Printer 











Figure 5-1 Basic batch flow 
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5.2 Job flow 


z/OS uses a job entry subsystem (JES) to do the following: 


> Receive jobs into the operating system 
> Schedule them for processing by z/OS 
> Control their output processing 


JES is the component of the operating system that provides supplementary job 
management, data management, and task management functions such as scheduling, 
control of job flow, and spooling. 


z/OS has two versions of JES: JES2 and JES3. The JES2 version is most common and is 
used throughout this text. JES2 (and JES3) have many functions and features, but their 
most basic functions are as follows: 


> Accept jobs submitted in various ways. This might be with a SUBMIT command 
from ISPF, from a card reader (very rare!), or over a network. 

> Queue jobs waiting to be executed. Multiple queues can be defined for various 
purposes. 

> Send a job to an initiator that requests the next job in the appropriate queue. 

> Accept printed output from the job while it is running and queue the output. 

> Optionally, print the output. 


JES uses one or more disk data sets for spooling. JES combines multiple spool data sets 
(if present) into a single conceptual data set. The internal format is not in a standard 
access-method format and is not written or read directly by applications. Input jobs and 
printed output from many jobs are stored in the single (conceptual) spool data set. In a 
small z/OS system the spool data sets might be a few hundred cylinders of disk space; in 
a large installation they might be many complete volumes of disk space. 


Spool simply means to queue and hold data in card-image format (for input) or printed 
format (for output). JES2 is described more fully in 5.14, “Job and output management 
with JES” on page 5-21. 


5.3 Initiators 


An initiator is a standard z/OS program. It is normally running in several address spaces 
(“multiple initiators”). An initiator manages the running of batch jobs, one at a time, in 
the same address space. If ten initiators are active (in ten address spaces), then ten batch 
jobs can run at the same time. JES does some JCL processing, but the initiator does the 
key JCL work. 
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In order to run multiple jobs asynchronously, the system must perform a number of 
functions: 


> It must select jobs from the input queues (JES does this). 

> It must ensure that required data sets are available. This might mean mounting tapes 
or placing required disk drives online. 

It must ensure that multiple jobs (including TSO users and other interactive 
applications) do not conflict in data set usage. 

It must ensure that single-user devices, such as tape drives, are allocated correctly. 
It must ensure that sufficient disk space is available for output data sets. 

It must find the executable programs requested for the job. 

It must clean up after the job ends and then request the next job. 

All this must be done in a manner that produces no deadlocks. 


Vv 


vvvvy 


Most of this work is done by the initiator, based on JCL information for each job. The 
most complex function is to ensure there are no conflicts due to data set utilization. For 
example, if two jobs try to write in the same data set at the same time (or one reads while 
the other writes), there is a conflict.! This event would normally result in corrupted data. 
The primary purpose of JCL is to tell an initiator what is needed for the job. 


The prevention of conflicting data set usage is critical to z/OS and is one of the defining 
characteristics of the operating system. When the JCL is properly constructed (which is 
the normal case) the prevention of conflicts is automatic. For example, ifjob A and job B 
both want to write in a particular data set, the system (via the initiator) will not permit 
both jobs to be run at the same time. Whichever job starts first will cause an initiator 
attempting to run the other job to wait until the first job completes. 


This function is built on the DISP= option in one of the JCL statements and is discussed 
several times in this chapter. It can be a bit difficult to understand because it is not a 
security control. It is an integrity control that the job owner can defeat if he wishes. 


5.4 Symbolic file system 
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z/OS normally uses a symbolic file system,” and this is another defining characteristic of 
this operating system. It applies a naming redirection between a data set-related name 
used in a program and the actual data set used during execution of that program. This is 
illustrated in Figure 5-2 on page 5-5. 


' There are cases where such usage is correct and JCL can be constructed for these cases. In the case of simple 
batch jobs, such conflicts are normally unacceptable. 

> This applies to normal traditional processing. Some languages, such as C, have defined interfaces that bypass 
this function. 
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DDNAME DSNAME 


Program JCL for JOB 


OPEN FILE=XYZ 
READ FILE=XYZ 


MY.PAYROLL 





CLOSE FILE=XYZ 














Figure 5-2. DDNAME and DSNAME 


In this illustration we have a program, in some arbitrary language, that wants to open and 
read a data set.> When the program is written, the name XYZ is arbitrarily selected to 
reference the data set. The program can be compiled and stored as an executable. When 
someone wants to run the executable program, a JCL statement must be supplied that 
relates the name XYZ to an actual data set name. This JCL statement is a DD statement. 
The symbolic name used in the program is a DDNAME and the real name of the data set 
is a DSNAME. 


The program can be used to process different input data sets simply by changing the 
DSNAME in the JCL. This becomes significant for large commercial applications that 
might use dozens of data sets in a single execution of the program. A payroll program for 
a large corporation is a good example. This can be an exceptionally complex application 
that might use hundreds of data sets. The same program might be used for different 
divisions in the corporation by running it with different JCL. Likewise, it can be tested 
against special test data sets by using a different set of JCL. 


3 The pseudo-program uses the term fi/e, as is common in most computer languages. 
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DDNAME DSNAME 


Program JCL for JOB 


OPEN FILE=XYZ 
READ FILE=XYZ 





DIV1.PAYROLL 





CLOSE FILE=XYZ 














Figure 5-3 Symbolic file name - same program, but another data set 


The firm could use the same company-wide payroll application program for different 
divisions and only change a _ single parameter in the JCL card (the 
DD DSN=DIV1.PAYROLL. DIV1.PAYROLL would access the unique data set appropriate 
to DIVision 1. This demonstrates the power and flexibility provided by JCL and 
symbolic data set names. 


This DDNAME - JCL - DSNAME processing applies to all traditional z/OS work 
although it may not be apparent in many cases. For example, when ISPF is asked to edit a 
data set, it builds the internal equivalent of a DD statement and then opens the requested 
data set via that DD statement. The ISPF user does not see this processing—it takes place 
“under the covers.” 


5.5 What JCL is 
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Job Control Language (JCL) is used to tell the system what program to execute, followed 
by a description of program inputs and outputs. It is possible to submit JCL for batch 
processing or start a JCL PROC, which is considered a started task. The details of JCL 
can be complicated but the general concepts are quite simple. Also, a small subset of JCL 
accounts for at least 90% of what is actually used. This chapter discusses selected JCL 
options. 


While application programmers need some knowledge of JCL, the production control 
analyst responsible must be highly proficient with JCL, to create, monitor, correct and 
re-run the company’s daily batch workload. 


: Again, we are ignoring some of the operational characteristics of the z/OS UNIX interfaces of z/OS. The 
discussion here applies to all traditional z/OS usage. 
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There are three basic JCL statements: 


JOB Provides a name to the system for this batch workload. It can optionally 
include accounting information and a few job-wide parameters. 


EXEC Provides the name of a program to execute. There can be multiple EXEC 
statements in a job. Each EXEC statement within the same job is a job step. 


DD The Data Definition provides inputs and outputs to the execution program 
on the EXEC statement. This statement links a data set or other I/O device 
or function toa DDNAME coded in the program. DD statements are 
associated with a particular job step. 


Figure 5-4 shows the basic JCL coding syntax. 





JCL must be uppercase 


Forward slash in column 1 and 2 
| Name (1-8 characters) follow the slashes 








Space separators 


/IIOBNAME JOB 

/ISTEPNAME EXEC 

//DDNAME DD 

//* comment - upper or lower case 
/* _...end of JCL stream 











Figure 5-4 Basic JCL coding syntax 
Example 5-1 shows some sample JCL. 


Example 5-1 JCL example 


//MYJOB JOB 1 
//MYSORT EXEC PGM=SORT 
//SORTIN DD DISP=SHR,DSN=ZPROF .AREA. CODES 
//SORTOUT DD SYSOUT=* 
//SYSOUT DD SYSOUT=* 
//SYSIN DD * 
SORT FIELDS=(1,3,CH,A) 
/* 


In the TSO/ISPF chapter, the same routine was executed from the TSO READY prompt. 
Each JCL DD statement is equivalent to the TSO ALLOCATE command. The TSO 
ALLOCATE command and the JCL DD statement associate a z/OS data set with a 
ddname, which is recognized by the program as an input or output. The difference in 
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5.6 JOB, 


method of execution is that TSO executes the sort in the foreground while JCL is used to 
execute the sort in the background, or batch. 


When submitted for execution: 


MYJOB Is ajob name the system associates with this workload. 

MYSORT Is the stepname, which instructs the system to execute the SORT 
program. 

SORTIN On the DD statement, this is the ddname. The SORTIN ddname is 


coded in the SORT program as a program input. The data set name 
(DSN) on this DD statement is ZPROF.AREA.CODES. The data set can 
be shared (DISP=SHR) with other system processes. The data content 
of ZPROF.AREA.CODES is SORT program input. 


SORTOUT This ddname is the SORT program output. 


SYSOUT SYSOUT=* specifies to send system output messages to the Job Entry 
Subsystem (JES) print output area. It is possible to send the output to a 
data set. 

SYSIN DD * is another input statement. It specifies that what follows is data or 


control statements. In this case, it is the sort instruction telling the 
SORT program which fields of the SORTIN data records are to be 
sorted. 


We use JCL statement in this text; some z/OS users use the term JCL card even though 
the JCL is in a disk library. 


EXEC and DD operands 


The JOB, EXEC and DD statements have many operands providing the system with 
explicit instructions and information. When you find it necessary to use these operands, a 
JCL reference manual or book is recommended. See “z/OS JCL and Utilities Reference” 
on page H-1. 


5.6.1 JOB operands 


JOB JCL statement //MYJOB JOB 1 is a job card with name MYJOB. The 1 is a job card 
accounting field that can be subject to system exits that might be used for charging 
system users. Some common JOB card operands that could be included are: 


REGION= Value requesting specific memory resources allocated to this job 
NOTIFY= Message can be sent to a TSO userid, following job completion 
USER= Job will assume the authority of userid specified 

TYPRUN= It is possible to submit the job on HOLD, to be released later 
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CLASS= 


MSGCLASS= 
MSGLEVEL= 


Example: 


Direct job JCL statement to a specific input queue, installation 
specific 

Direct job output to a specific output queue, installation specific 
Controls amount of system message to be received 


//MYJOB JOB 1,NOTIFY=&SYSUID, REGION=6M 


5.6.2 EXEC operands 


The EXEC JCL statement //MYSTEP EXEC has a stepname of MYSTEP. Following the 
EXEC is either PGM=(executable program name) or a JCL PROC name. When a JCL 
PROC is present, then the operands will be the variable substitutions required by the JCL 
PROC. Common operands found on the EXEC PGM= statement are: 


PARM= 
COND= 


TIME= 


Example: 


Parameters known by and passed to the program. 

Boolean logic for controlling execution of other EXEC steps in this 
job....IF, THEN, ELSE JCL statements exist that are superior to using 
COND, however, lots of old JCL may exist in production environments 
using this statement. 

Imposes a time limit. 


//MYSTEP EXEC PGM=SORT 


5.6.3 DD operands 


The DD JCL statement //MYDATA DD has a ddname of MYDATA. DD, the Data Definition, 
has significantly more operands than the JOB or EXEC statements. The DD JCL 
statement can be involved with many aspects of defining or describing attributes of the 
program inputs or outputs. Some common DD statement operands are: 


DSN= 


DISP= 


SPACE= 
SYSOUT= 
VOL=SER= 
UNIT= 
DEST= 
DCB= 


The name of the data set; this can include creation of temporary 
data sets or a reference back to the data set name. 

Data set disposition at step start (new, shr, old, mod), at step end 
(catlg, keep, delete, pass) and if the step abends (catlg, keep, 
delete, pass). 

Amount of disk storage requested for a new data set. 

Defines a print location (anthe output queue or data set). 
Volume name, disk name or tape name 

System disk, tape, special device type or esoteric (local name). 
Routes output to a remote destination. 

Data set control block, numerous sub operands. 

Most common sub operands: 
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LRECL= Logical record length. Number of bytes/characters in each 
record. 
RECFM= Record format, fixed, blocked, variable, etc. 


BLOCKSIZE= _ Store records in a block of this size, typically a multiple of 
LRECL. A value of 0 will let the system pick the best value. 
DSORG= Data set organization—sequential, partitioned, etc. 
LABEL= Tape label expected (No Label or Standard Label followed by 
data set location). A tape can store multiple data sets; each data 
set on the tape is in a file position. The first data set on tape is 


file 1. 

DUMMY Results in a null input or throwing away data written to this 
ddname. 

ao Input data or control statements follow—a method of passing 
data to a program from the JCL stream. 

* DLM= Everything following is data input (even //) until the two 
alphanumeric or special characters specified in column | are 
encountered. 


5.7 Data set disposition, DISP operand 


All JCL parameters are important, but the DISP function is perhaps the most important 
for DD statements. The complete parameter has these fields: 


DISP=(status,normal end,abnormal end) 
DISP=(status,normal end) 
DISP=status 


where status can be NEW, OLD, SHR, or MOD: 


NEW Indicates that a new data set is to be created. This job has exclusive access to 
the data set while it is running. The data set must not already exist. 

OLD Indicates that the data set already exists and that this job is to have exclusive 
access to it while it is running. 

SHR Indicates that the data set already exists and that several concurrent jobs can 
share access while they are running. All the concurrent jobs must specify 
SHR. 

MOD Indicates that the data set already exists and the current job must have 
exclusive access while it is running. If the current job opens the data set for 
output, the output will be appended to the current end of the data set. 


The normal end parameter indicates what to do with the data set (the disposition) if the 
current job step ends normally. Likewise, the abnormal end parameter indicates what to 
do with the data set if the current job step ABENDs. The options are the same for both 
parameters: 


DELETE Means to delete (and uncatalog) the data set at the end of the job step. 
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KEEP Means to keep (but not catalog) the data set at the end of the job step. 
CATLG Means to keep and catalog the data set at the end of the job step. 
UNCATLG Means to keep the data set but uncatalog it at the end of the job step. 
PASS Means to allow a later job step to specify a final disposition. 


The default disposition parameters (for normal and abnormal end) are to leave the data 
set as it was before the job step started. (The catalog function was described previously in 
4.5.2, “Catalog” on page 4-9.) 


A primary purpose of the DISP parameter is to advise the system about data set 
enqueuing needed for this job to prevent conflicting use of the data set by other jobs. 


5.7.1 Creating new data sets 


If the DISP parameter for a data set is NEW, then additional information is needed. This 
includes: 


A data set name. 

The type of device for the data set. 

A volser if it is a disk or labeled tape. 

If a disk is used, the amount of space to be allocated for the primary extent must be 
specified. 

If it is a partitioned data set, the size of the directory must be specified. 

Optionally, DCB parameters can be specified. Alternately, the program that will write 
the data set can provide these parameters. 


vvvy 


vv 


The DISP and data set names have already been described. Briefly, the other parameters 
are: 


Volser: The format for this in a DD statement is VOL=SER=xxxxxx, where 
XXxxxx Is the volser. The VOL parameter can specify other details, 
which is the reason for the format. 

Device type: There are a number of ways to do this, but UNIT=xxxx is the most 
common. The xxxx can be an IBM device type (such as 3390), or a 
specific device address (such as 300), or an esoteric name defined by 
the installation (such as SYSDA). A common convention uses 
SYSDA to represent any available disk volume. 

Member name Remember that a library (or partitioned data set, PDS) member can 
be treated as a data set by many applications and utilities. The format 
DSNAME=2PROF.LIB.CNTL(TEST) is used to reference a specific 
member. If the application or utility program is expecting a 
sequential data set, then either a sequential data set or a member of a 
library must be specified. A whole library name (without a specific 
member name) can be used only if the program/utility is expecting a 
library name. 
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Space: 

The SPACE DD parameter is required for allocating data sets on DASD. It identifies the 
space allocation required for your data set. Before a data set can be created on disk, the 
system must know how much space the data set will require and how the space is to be 
measured. 


There are a number of different formats and variations for this. Common examples are: 


SPACE=(TRK, 10) 10 tracks, no secondary extents 
SPACE=(TRK, (10,5) ) 10 tracks primary, 5 each secondary 
SPACE=(CYL,5) Can use CYL (cylinders) instead of TRK 
SPACE=(TRK, (10,5,8) ) PDS with 8 directory blocks 


SPACE=(1000, (50000,10000)) Primary 50000 records@1000 byte each 


In the basic case, there are two parameters for SPACE. These are the unit of measure and 
the amount of space. The unit of measure can be tracks, cylinders, or the average block 
size.” The amount of space typically can have up to three subparameters: 


> The first parameter is the primary extent size, expressed in terms of the unit of 
measure. The system will attempt to obtain a single extent (contiguous space) with 
this much space. If the system cannot obtain this space in not more than five extents 
(on a single volume) before the job starts, the job is failed. 


> The second parameter, if used, is the size of each secondary extent. The system does 
not obtain this much space before the job starts and does not guarantee that this space 
is available. The system obtains secondary extents dynamically, while the job is 
executing. In the basic examples shown here the secondary extents are on the same 
volume as the primary extent. 


> The third parameter, if it exists, indicates that a partitioned data set (library) is being 
created. This is the only indication that a PDS is being created instead of another type 
of data set. The numeric value is the number of directory blocks (255 bytes each) that 
are assigned for the PDS directory. (Another JCL parameter is needed to create a 
PDSE instead of a PDS). 


If the space parameter contains more than one subparameter, then the whole space 
parameter must be inclosed in parentheses. 


5.8 Continuation and concatenation 
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As a consequence of the limitations of the number of characters that could be contained 
in single 80-column punched cards used in earlier systems, z/OS introduced the concepts 
of continuation and concatenation. Therefore, z/OS retained these conventions in order to 
minimize the impact on previous applications and operations. 


> The unit of measure can also be KB and MB but these are not as commonly used. 
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Continuation of JCL syntax involves a comma at the end of the last complete operand. 
The next JCL line would include // followed by at least one space, then the additional 
operands. JCL operand syntax on a continuation line must begin on or before column 
sixteen. 


//JOBCARD JOB 1,REGION=8M,NOTIFY=ZPROF 


The JCL statement above would have the same result as the following continuation JCL: 


//JOBCARD JOB 1, 
// REGION=8M, 
// NOTIFY=ZPROF 


An important feature of DD statements is the fact that a single ddname can have multiple 
DD statements. This is called concatenation. 


The following JCL indicates that data sets are concatenated: 


//DATAIN DD DISP=OLD,DSN=MY.INPUT1 
// DD DISP=OLD,DSN=MY . INPUT2 
// DD DISP=SHR,DSN=YOUR. DATA 


Concatenation applies only to input data sets. The data sets are automatically processed 
in sequence. In the example, when the application program reads to the end of 
MY. INPUT1, the system will automatically open MY.INPUT2 and start reading it. The 
application program is not aware that it is now reading a second data set. This continues 
until the last data in the concatenation is read; at that time the application receives an 
end-of -file indication. 


5.9 Reserved DDNAMES 


A programmer can select almost any name he desires for DD names to be used by his 
program. It is nice if a programmer selects meaningful names, as best he can within the 
8-character limit, but this is not required. There are a few reserved DD names that a 
programmer cannot use (all of these are optional DD statements): 


//JOBLIB DD ... 
//STEPLIB DD ... 
//JOBCAT DD ... 
//STEPCAT DD ... 
//SYSABEND DD ... 
//SYSUDUMP DD ... 
//SYSMDUMP DD ... 
//CEEDUMP DD ... 


A JOBLIB DD statement, placed just after a JOB statement, specifies a library that 
should be searched first for the programs executed by this job. A STEPLIB DD 
statement, placed just after an EXEC statement, specifies a library that should be 
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searched first for the program executed by the EXEC statement. A STEPLIB overrides a 
JOBLIB if both are used. 


The JOBCAT and STEPCAT are used to specify private catalogs. The most recent z/OS 
releases no longer support this function. It was rarely used. Nevertheless, these DD 
names should be treated as reserved names. 


The SYSABEND, SYSUDUMP, SYSMDUMP, and CEEDUMP DD statements are used 
for various types of memory dumps that may be generated when a program ABENDs. 


5.10 JCL procedures (PROC) 
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Some programs and tasks require a larger amount of JCL than a user can easily enter. 
JCL for these functions can be entered in procedure libraries. A procedure library 
member contains part of the JCL for a given task. It usually contains the fixed, 
unchanging JCL needed for the task. The user of the procedure supplies the variable part 
of the JCL for a specific job. These procedures are sometimes known as cataloged 
procedures. This is not a meaningful name; procedures are not related to the system 
catalogs and the name is a carryover from another operating system. 


Example 5-2 shows an example of a JCL PROC or JCL procedure. 


Example 5-2. Example JCL procedure 


//MYPROC PROC 

//MYSORT EXEC PGM=SORT 

//SORTIN DD DISP=SHR, DSN=&SORTDSN 
//SORTOUT DD SYSOUT=* 

//SYSOUT DD SYSOUT=* 

// PEND 


Much of this JCL should be recognizable now. New JCL functions presented here 
include: 


> PROC and PEND statements are unique to procedures. They are used to identify the 
beginning and end of the JCL procedure. 


> The PROC is preceded by a label or name; the name defined in Example 5-2 is MYPROC. 
> JCL variable substitution is the reason JCL PROCs are used. &SORTDSN is the only 
variable in Example 5-2. 


In Example 5-3 we use Example 5-2 as an inline procedure. 


Example 5-3 Sample inline procedure 
//MYJOB JOB 1 
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//MYPROC PROC 

//MYSORT EXEC PGM=SORT 

//SORTIN DD DISP=SHR, DSN=&SORTDSN 
//SORTOUT DD SYSOUT=* 

//SYSOUT DD SYSOUT=* 

// PEND 


//STEP1 EXEC MYPROC, SORTDSN=ZPROF .AREA.CODES 
//SYSIN DD * 
SORT FIELDS=(1,3,CH,A) 


> When MYJOB is submitted, the JCL from Example 5-2 on page 5-14 is effectively 
substituted for EXEC MYPROC. The value for &SORTDSN must be provided. 


> SORTDSN and its value were placed on a separate line, a continuation of the EXEC 
statement. Notice the comma after MYPROC. 


> //SYSIN DD * followed by the SORT control statement will be appended to the 
substituted JCL. 


5.10.1 JCL PROC statement override 


When an entire JCL PROC statement needs to be replaced, then a JCL PROC override 
statement can be used. An override statement has the following form: 


//stepname.ddname DD ... 


Example 5-4 shows an example of overriding the SORTOUT DD statement in MYPROC. 
Here, SORTOUT is directed to a newly created sequential data set. 


Example 5-4 Sample procedure with statement override 


//MYJOB JOB 1 


//MYPROC PROC 

//MYSORT EXEC PGM=SORT 

//SORTIN DD DISP=SHR, DSN=&SORTDSN 
//SORTOUT DD SYSOUT=* 

//SYSOUT DD SYSOUT=* 

// PEND 


//STEP1 EXEC MYPROC, SORTDSN=ZPROF .AREA.CODES 
//MYSORT.SORTOUT DD DSN=ZPROF .MYSORT.OUTPUT, 


// DISP=(NEW,CATLG) ,SPACE=(CYL,(1,1)), 
// UNIT=SYSDA, VOL=SER=SHARED, 
// DCB=(LRECL=20, BLKSIZE=0, RECFM=FB, DSORG=PS) 


//SYSIN DD * 
SORT FIELDS=(1,3,CH,A) 
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5.11 Submit JCL to background for batch processing 


Using UNIX and AIX as an analogy, a UNIX process can be processed in the background 
by appending an ampersand (&) to the end of a command or script. Pressing Enter then 
submits the job as a background process. In z/OS terminology, JCL is submitted for batch 
processing. Batch processing is a rough equivalent to UNIX background processing. The 
job runs independent of the interactive session. The term batch is used because it is a 
large collection of jobs that can be queued, waiting their turn to be executed when the 
needed resources are available. 


ISPF editor command line SUBmit and press Enter. 


ISPF Command Shell SUBmit ‘USER.JCL’ 

where the data set is sequential. 
ISPF Command Line TSO SUBmit "USER.JCL’ 

where the data set is sequential. 
ISPF Command Line TSO SUBmit ‘USER.JCL(MYJOB)’ 


where the data set is a library or partitioned data set 
containing member MYJOB. 


5.11.1 SDSF 
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Once a JCL job is submitted, System Display and Search Facility (SDSF)° is commonly 
used to review the output for successful completion or review and correct JCL errors. 
SDSF is a software product whose primary purpose is to display printed output held in 
the JES spool area. Much of the printed output sent to JES by batch jobs (and other jobs) 
is never actually printed. Instead it is inspected using SDSF and deleted or used as 
needed. 


SDSF provides a number of additional functions, including: 


Viewing the system log and searching for any literal string 
Entering system commands 

Controlling job processing (hold, release, cancel, and purge jobs) 
Monitoring jobs while they are being processed 

Displaying job output before deciding to print it 

Controlling the order in which jobs are processed 

Controlling the order in which output is printed 

Controlling printers and initiators 


vvvvvvvyy 


© As with so many software products, the name conveys no useful information about its purpose. 
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Figure 5-5 SDSF panel hierarchy 


View the JES2 output files 


You can see the JES output data sets created during the execution of your batch job. They 
are saved on the JES spool data set. You can see the JES data sets in any JES queue: 


I Input 

DA Execution queue 
O Output queue 

H Held queue 

ST Status queue 


For output and held queues, you cannot see those JES data sets you requested to be 
automatically purged by setting a MSGCLASS out sysout CLASS that has been defined 
to not save output. Also, depending on the MSGCLASS you chose on the JOB card, the 
sysouts can be either in the Output queue or in the Held queue. 
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Screen 1 


COMMAND INPUT ===> _ 
PREFIX=* DEST=(ALL) OWNER=*x SYSNAME= 
NP DDNAME StepName ProcStep DSID Owner 


JESMSGLG JES2 2 MIRIAM 
JESICL JES2 3 MIRIAM 
JESYSMSG JES2 4 MIRIAM 





Display Eilter View Print Options Help 


Display Filter View Print Options Help 


SDSF JOB DATA SET DISPLAY - JOB MIRIAM2 (JOB26044) 


45450 


SDSF HELD OUTPUT DISPLAY ALL CLASSES LINES 44 


COMMAND INPUT ===> 

PREFIX=* DEST=(ALL) OWNER=* SYSNAME= 

NP JOBNAME JobID Owner Prty C ODisp Dest 
a. MIRIAM2 JOB26044 MIRIAM 144 T HOLD LOCAL 
Screen 2 


Dest 

LOCAL 
LOCAL 
LOCAL 


LINE 1-1 (1) 


SCROLL ===> PAGE 
Tot-Rec Tot- 
44 
LINE 1-3 (3) 
SCROLL ===> PAGE 


Rec-Cnt Page 
20 
12 
12 








Figure 5-6 SDSF viewing the JES2 Output files 


The first screen shown in Figure 5-6 displays a list of the jobs we submitted and whose 
output we directed to the HELD (Class T) queue, as identified in the MSGCLASS=T 
parameter on the job card. In our case only one job has been submitted and executed. 


Therefore, we only have one job on the Held queue. 


Issuing a ? command in the NP column displays the output files generated by job 7359. 
The second screen, shown in Figure 5-6, displays three ddnames: the JES2 messages log 
file, the JES2 JCL file, and the JES2 system messages file. This option is useful when 
you are seeing jobs with many files directed to SYSOUT and you want to display one 
associated with a specific step. You issue an S in the NP column to select a file you want. 


To see all files, instead of a ?, type S in the NP column; the result is presented in 


Figure 5-7 on page 5-25. 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter5 batch and jel.fm 


JES2 Job Log 
The following is an example of a JES2 Job Log. 
Example 5-5 JES2 Job Log 


JES2 J0B LOG -- SYSTEM SC64 -- NODE 
13.19.24 JOB26044 ---- WEDNESDAY, 27 AUG 2003 ---- 


13.19.24 JOB26044 IRRO1OI USERID MIRIAM IS ASSIGNED TO THIS JOB. 
13.19.24 JOB26044 ICH70001I MIRIAM LAST ACCESS AT 13:18:53 ON WEDNESDAY, AUGU 


13.19.24 JOB26044 $HASP373 MIRIAM2 STARTED - INIT 1 - CLASS A - SYS SC64 
13.19.24 JOB26044 IEF4031 MIRIAM2 - STARTED - ASID=0027 - SC64 

13.19.24 JOB26044_ - --TIMINGS (MINS.)-- 
13.19.24 JOB26044 -JOBNAME STEPNAME PROCSTEP RC —_EXCP CPU SRB CLOCK 
13.19.24 JOB26044 -MIRIAM2 STEP1 00 9 -00 -00 -00 
13.19.24 JOB26044 IEF404I MIRIAM2 - ENDED - ASID=0027 - SC64 

13.19.24 JOB26044 -MIRIAM2 ENDED. NAME-MIRIAM TOTAL CPU TIME= 





13.19.24 JOB26044 $HASP395 MIRIAM2 ENDED 
eaccce JES2 JOB STATISTICS ------ 
27 AUG 2003 JOB EXECUTION DATE 
11 CARDS READ 
44 SYSOUT PRINT RECORDS 
0 SYSOUT PUNCH RECORDS 
3 SYSOUT SPOOL KBYTES 
0.00 MINUTES EXECUTION TIME 
1 //MIRIAM2 JOB 19,MIRIAM,NOTIFY=&SYSUID,MSGCLASS=T, 
// MSGLEVEL=(1,1) ,CLASS=A 
IEFC6531 SUBSTITUTION JCL - 19,MIRIAM,NOTIFY=MIRIAM,MSGCLASS=T ,MSGLEVE 
2 //STEP1 EXEC PGM=IEFBR14 


1 Pe sag i 0 Me a SI Rs ed a tt Eee * 
//* THIS IS AN EXAMPLE OF A NEW DATA SET ALLOCATION 

//* Se 2 eZ See eee BER ee Clee ene eee wesc e cee tee ceee * 
3 //NEWDD DD DSN=MIRIAM.IEFBR14.TEST1.NEWDD, 

// DISP=(NEW, CATLG, DELETE) ,UNIT=SYSDA, 

// SPACE=(CYL, (10,10,45)) , LRECL=80, BLKSIZE=3120 
4 //SYSPRINT DD SYSOUT=T 

/* 


ICH70001I MIRIAM LAST ACCESS AT 13:18:53 ON WEDNESDAY, AUGUST 27, 2003 
IEF2361 ALLOC. FOR MIRIAM2 STEP1 

IGD1001 390D ALLOCATED TO DDNAME NEWDD DATACLAS ( ) 

IEF2371 JES2 ALLOCATED TO SYSPRINT 

IEF1421 MIRIAM2 STEP1 - STEP WAS EXECUTED - COND CODE 0000 


IEF2851 MIRIAM. IEFBR14.TEST1.NEWDD CATALOGED 
IEF285I VOL SER NOS= SBOX38. 
IEF2851 MIRIAM.MIRIAM2.J0B26044.D0000101.? SYSOUT 


IEF3731 STEP/STEP1 /START 2003239.1319 
IEF3741 STEP/STEP1 /STOP 2003239.1319 CPU OMIN 00.00SEC SRB OMIN 00.00S 
IEF3751 JOB/MIRIAM2 /START 2003239.1319 
IEF3761 JOB/MIRIAM2 /STOP 2003239.1319 CPU OMIN 00.00SEC SRB OMIN 00.00S 
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5.12 Utilities 


z/OS includes a narrow and somewhat uncertain definition of utility programs. Initially, 
utility programs were those programs documented in the early OS/360 Utilities manual. 
By common acceptance of the MVS user community, a few programs have been added to 
this set and several have been removed (by becoming obsolete). There is no specific 
definition of what constitutes a z/OS utility program today, but common usage includes 
only a few z/OS-provided programs as utilities. 


A set of basic utilities is described in Appendix C, “Utility Programs”. 


Considering the wide-ranging functions and abilities of z/OS, there is an astonishingly 
small number of system-provided utilities. Many small, obvious, and useful functions are 
not provided. This has produced a large number of customer-written utility programs 
(although most users refrain from naming them utilities) and many of these are widely 
shared by the user community. Independent software vendors also provide many similar 
products (for a fee). 


5.13 System libraries 


5-20 


z/OS has many standard system libraries. A brief description of several libraries is 
appropriate here. The traditional libraries include: 


> SYS1.PROCLIB. This library contains JCL procedures distributed with z/OS. In 
practice, there are many other JCL procedure libraries (supplied with various 
program products) concatenated with it. 

> SYS1.PARMLIB. This library contains control parameters for z/OS and for some 
program products. In practice, there may be other libraries concatenated with it. 

> SYS1.LINKLIB. This library contains many of the basic execution modules of the 
system. In practice, it is one of a large number of execution libraries that are 
concatenated together. 

> SYS1.LPALIB. This library contains system execution modules that are loaded into 
the link pack area when the system is initialized. There may be several other libraries 
concatenated with it. 

> SYS1.NUCLEUS. This library contains the basic supervisor (“kernel”) modules of 
z/OS. 


All of these libraries are standard PDS data sets and are found on the system disk 
volumes. They are discussed in more detail in 17.3, “z/OS System Libraries” on 
page 17-8. 
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5.14 Job and output management with JES 


Let us introduce the Job Entry Subsystem (JES) concept via two examples. 


Example 1 

Imagine that you are a programmer and you want to compile and execute your source 
program. As an IT professional, you are developing a program for a non-skilled user. 
Your program is supposed to read a couple of files, and to write another couple and then 
produce a printed report. What sorts of functions are desired in the operating system to 
fulfill your needs? Let us see. It is worthless to send your source code through CICS, 
IMS or WebSphere. They are not compilers. These products aim to offer computer 
services to non-IT people. 


First you need a sort of special language to inform the operating system about your 
needs. This language is Job Control Language (JCL). Refer to 5.5, “What JCL is” on 
page 5-6 for a full definition of JCL. In the JCL you specify the following: 


> Who you are (important for security reasons). 
> Which resources (programs, files, memory) you want from the system: 

— Load the compiler code in memory. 

— Make accessible to the compiler your source code, that is, when the compiler asks 
for a read, your source statements are brought to the compiler memory. 

— What amount of memory the system needs to allocate to accommodate the 
compiler code, I/O buffers, and working areas. 

— Make accessible to the compiler an output disk data set to receive the object code. 

— Make accessible to the compiler a print file where it will tell you your eventual 
mistakes. 

— At compilation end tell the operating system that now your produced object code 
needs to be loaded into memory (however, this should not be done if the 
compilation failed). 

— What amount of memory is needed for your program. 

— Make accessible to your program all the input and output files. 

— Make accessible to your program a printer for eventual messages. 


Second, you need a component in the operating system to: 


Understand JCL (correcting eventual errors). 

Convert JCL to control blocks describing the needed resources. 

Allocate the required resources (programs, memory, files). 

Schedule the execution on a timely basis, for example, your program only runs if the 
compilation succeeds. 

> Free the resources when the program is done. 


vvvy 


The components that do the above are the basic control program subcomponents JES and 
the initiator. 
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Think of JES as the manager of the jobs waiting in a queue. It manages the priority of the 
set of jobs and their associated input data and output results. The initiator uses the 
statements on the JCL cards to specify the resources required of each individual job once 
it has been released (dispatched) by JES. 


Your JCL as described is called a job—in this case formed by two sequential steps, the 
compilation and execution. The steps in a job are always executed sequentially. The job 
must be submitted to JES in order to be executed. In order to make your task easier, z/OS 
provides a set of procedures in SYS1.PROCLIB. A procedure is a set of JCL statements 
ready to be executed. 


Example 5-6 on page 5-23 shows a JCL procedure that can compile, link-edit and 
execute a program. The first step identifies the COBOL compiler, as declared in //COBOL 

EXEC PGM=IGYCRCTL. The statement //SYSLIN DD describes the output of the 
compiler (object module). 


The object module is the input for the second step, which performs link-editing (through 
program IEWL). Link-editing is needed to resolve external references and bring in or 
link the previously developed common routines (a type of code re-use). 


In the third step, the program is executed. 
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Example 5-6 Procedure to compile, linkedit, and execute programs 


000010 //IGYWCLG PROC LNGPRFX='IGY.V3R2M0',SYSLBLK=3200, 


000020 // LIBPRFX='CEE' ,GOPGM=G0 

000030 //* 

000040 | [BERRRRRRRR RRR RRR ER ERE REE ER ERE REE REE RR ER ERERER EKER ERE REE ERE RERERER 
000050 //* * 
000060 //* Enterprise COBOL for z/OS and 0S/390 bd 
000070 //* Version 3 Release 2 Modification 0 * 
000080 //* * 
000090 //* LICENSED MATERIALS - PROPERTY OF IBM. * 
000100 //* y 
000110 //* 5655-G53 5648-A25 (C) COPYRIGHT IBM CORP. 1991, 2002 = 
000120 //* ALL RIGHTS RESERVED * 
000130 //* ~ 
000140 //* US GOVERNMENT USERS RESTRICTED RIGHTS - USE, - 
000150 //* DUPLICATION OR DISCLOSURE RESTRICTED BY GSA 7 
000160 //* ADP SCHEDULE CONTRACT WITH IBM CORP. i. 
000170 //* ~ 


000180 | [BERRRRRRRR RRR RRR ER ERE RER ER ER ERE REE REE REE ERE RER ER ER ER ER ERE RE RERERER 


000190 //* 

000300 //COBOL EXEC 
000310 //STEPLIB DD 
000320 // 

000330 //SYSPRINT DD 


000340 //SYSLIN DD 
000350 // 
000360 // 
000370 //SYSUT1 DD 
000440 //LKED EXEC 


000450 //SYSLIB 
000460 // 
000470 //SYSPRINT DD 


DD 


000480 //SYSLIN DD 
000490 // DD 
000500 //SYSLMOD DD 
000510 // 
000520 //SYSUT1 DD 
000530 //G0 EXEC 
000540 // 
000550 //STEPLIB DD 
000560 // 


000570 //SYSPRINT DD 
000580 //CEEDUMP DD 
000590 //SYSUDUMP DD 
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PGM=IGYCRCTL, REGION=2048K 
DSNAME=&LNGPRFX. .SIGYCOMP, 

DISP=SHR 

SYSOUT=* 

DSNAME=8&LOADSET ,UNIT=SYSDA, 
DISP=(MOD, PASS) , SPACE=(TRK, (3,3)), 
DCB= (BLKSIZE=&SYSLBLK) 

UNIT=SYSDA, SPACE=(CYL, (1,1)) 

PGM=HEWL, COND=(8,LT, COBOL) , REGION=1024K 
DSNAME=&LIBPRFX. .SCEELKED, 

DISP=SHR 

SYSOUT=* 
DSNAME=&&LOADSET , DISP= (OLD, DELETE) 
DDNAME=SYSIN 
DSNAME=8&GOSET (&GOPGM) , SPACE=(TRK, (10,10,1)), 
UNIT=SYSDA, DISP= (MOD, PASS) 

UNIT=SYSDA, SPACE=(TRK, (10,10) ) 

PGM=*. LKED.SYSLMOD, COND=((8,LT, COBOL) , (4,LT,LKED)), 
REGION=2048K 

DSNAME=&LIBPRFX. . SCEERUN, 

DISP=SHR 

SYSOUT=* 

SYSOUT=* 

SYSOUT=* 
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To invoke a procedure, you need to write some simple JCL as shown in Example 5-7. In 
this JCL we are adding other DD statements, one of which is: 


//COBOL.SYSIN DD * 
It contains the COBOL source code. 


Example 5-7 COBOL program 


000001 //COBOL1 JOB (POK,999) ,MGELINSKI,MSGLEVEL=(1,1) ,MSGCLASS=X, 
000002 // CLASS=A,NOTIFY=&SYSUID 

000003 /*JOBPARM SYSAFF=* 

000004 // JCLLIB ORDER=(IGY.SIGYPROC) 


000005 //* 

000006 //RUNIVP EXEC IGYWCLG,PARM.COBOL=RENT,REGION=1400K, 
000007 // PARM.LKED='LIST,XREF,LET,MAP' 
000008 //COBOL.STEPLIB DD DSN=IGY.SIGYCOMP, 

000009 // DISP=SHR 

000010 //COBOL.SYSIN DD * 

000011 IDENTIFICATION DIVISION. 

000012 PROGRAM-ID. CALLIVP1. 

000013 AUTHOR. IBM PROGRAMMER. 

000014 INSTALLATION. ITSO 

000015 DATE-WRITTEN. JUL 27, 2004. 

000016 DATE-COMPILED. 

000017 / 

000018 ENVIRONMENT DIVISION. 

000019 CONFIGURATION SECTION. 

000020 SOURCE-COMPUTER. IBM-390. 

000021 OBJECT-COMPUTER. IBM-390. 

000022 

000023 PROCEDURE DIVISION. 

000024 DISPLAY "***** HELLO WORLD *****" UPON CONSOLE. 
000025 STOP RUN. 

000026 

000027 //GO0.SYSOUT DD SYSOUT=* 

000028 // 


During the execution of a step, the program is controlled by z/OS, not by JES. To go a 
little further on job management, a spooling function is also needed. 
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Figure 5-7 Related actions with JCL 


Spooling is a process by which the system manipulates its work. This includes: 


> Using storage on direct access storage devices (DASD) as buffer storage to reduce 
processing delays when transferring data between peripheral equipment and a 
program to be run. 


> Reading and writing input and output streams on an intermediate device for later 
processing or output. 


> Performing an operation such as printing while the computer is busy with other work. 


There are two sorts of spooling: input and output. Both improve the performance of the 
program reading the input and writing the output. 


To implement input spooling in JCL, you declare // DD *, which defines one file whose 
content records are in JCL between the // DD * statement and the /* statements. All the 
logical records must have 80 characters. In this case this file is read and stored in a 
specific JES2 spool area (a huge JES file on disk). Later, when the program is executed 
and asks to read this data, JES2 picks up the records in the spool and delivers them to the 
program (at disk speed). 
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To implement output spooling in JCL, you specify the keyword SYSOUT on the DD 
statement. SYSOUT defines an empty file in the spool, allocated with logical records of 
132 characters in a printed format (EBCDIC/ASCH/UNICODE). This file is allocated by 
JES when interpreting a DD card with the SYSOUT keyword, and used later for the step 
program. Generally, after the end of the job, this file is printed by a JES function. 





JCL 





/DD1 DD* 
Program Serevent 





Printer 











Figure 5-8 Spooling 


Example 2 


Suppose now that you want to make a backup of one master file and then update the 
master file with records read-in from another file (the update file). If so, you need a job 
with two steps. In Step 1, your job reads the master file, and writes it to tape. In Step 2, 
another program (which can be written in COBOL) is executed to read a record from the 
update file and searches for its match in the master file. The program updates the existing 
record (if it finds a match) or adds a new record if needed. 


In this example, what kind of functions are needed in the operating system to meet your 
requirements? 

Build a job with two steps that specify the following: 

> Who you are 

> What resources are needed by the job, such as the following: 


— Load the backup program (that you already have compiled). 
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— How much memory the system needs to allocate to accommodate the backup 
program, I/O buffers, and working areas. 

— Make accessible to the backup program an output tape data set to receive the 
backup, a copy, and the master file data set itself. 

— At program end indicate to the operating system that now your update program 
needs to be loaded into memory (however, this should not be done if the backup 
program failed). 

— Make accessible to the update program the update file and master file. 

— Make accessible to your program a printer for eventual messages. 


Your JCL must have two steps, the first one indicating the resources for the backup 
program, and the second for the update program. Logically, the second step will not be 
executed if the first one fails for any reason. The second step will have a // DD SYSOUT 
statement to indicate the need for output spooling. 





First step 


[ Master l Master 






Program 


Program 


: Master 














Figure 5-9 Example 2 


The jobs are only allowed to start when there are enough resources available. In this way, 
the system is made more efficient: JES manages jobs before and after running the 
program; the base control program manages jobs during processing. 
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Two types of job entry subsystems are offered with z/OS: JES2 and JES3. This section 
discusses JES2. For a brief comparison of JES2 and JES3, see 5.16, “JES2 compared to 
JES3” on page 5-30. 


5.15 Job flow through the system 


Now after these two examples of jobs, let us see in more detail how a job is processed by 
the combination of JES and a batch initiator program. 


During the life of a job, JES2 and the base control program of z/OS control different 
phases of the overall processing. The job queues contain jobs that are waiting to run, 
currently running, waiting for their output to be produced, having their output produced, 
and waiting to be purged from the system. Generally speaking, a job goes through the 
following phases: 


Input 

Conversion 

Processing 

Output 

Print/punch (hard copy) 
Purge 
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Figure 5-10 Job flow through the system 
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1 


Input phase 


JES2 accepts jobs, in the form of an input stream, from input devices, from other 
programs through internal readers, and from other nodes in a job entry network. 


The internal reader is a program that other programs can use to submit jobs, control 
statements, and commands to JES2. Any job running in z/OS can use an internal 
reader to pass an input stream to JES2. JES2 can receive multiple jobs simultaneously 
through multiple internal readers. 


The system programmer defines internal readers to be used to process all batch jobs 
other than Started Tasks (STCs) and TSO requests. 


JES2 reads the input stream and assigns a job identifier to each JOB JCL statement. 
JES2 places the job’s JCL, optional JES2 control statements, and SYSIN data onto 
DASD data sets called spool data sets. JES2 then selects jobs from the spool data sets 
for processing and subsequent running. 


Conversion phase 


JES2 uses a converter program to analyze a job’s JCL statements. The converter takes 
the job’s JCL and merges it with JCL from a procedure library. The procedure library 
can be defined in the JCLLIB JCL statement, or system/user procedure libraries can 
be defined in the PROCxx DD statement of the JES2 startup procedure. Then, JES2 
converts the composite JCL into converter/interpreter text that both JES2 and the 
initiator can recognize. Next, JES2 stores the converter/interpreter text on the spool 
data set. If JES2 detects any JCL errors, it issues messages, and the job is queued for 
output processing rather than execution. If there are no errors, JES2 queues the job for 
execution. 


Processing phase 


In the processing phase, JES2 responds to requests for jobs from the z/OS initiators. 
JES2 selects jobs that are waiting to run from a job queue and sends them to z/OS 
initiators. 


An initiator is a system program belonging to z/OS but controlled by JES or by Work 
Load Manager (WLM), that starts a job allocating the required resources to allow it 
to compete with other jobs that are already running. 


JES2 initiators are initiators that are started by the operator or by JES2 automatically 
when the system initializes. They are defined to JES2 through JES2 initialization 
statements. The installation associates each initiator with one or more job classes in 
order to obtain an efficient use of available system resources. initiators select jobs 
whose classes match the initiator-assigned class, obeying the priority of the queued 
jobs. 


WLM initiators are started by the system automatically based on performance goals, 
relative importance of the batch workload, and the capacity of the system to do more 
work. The initiators select jobs based on their service class and the order they were 
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made available for execution. Jobs are routed to WLM initiators via a JOBCLASS 
JES2 initialization statement. 


4. Output phase 


JES2 controls all SYSOUT processing. SYSOUT is system-produced output; that is, 
all output produced by, or for, a job. This output includes system messages that must 
be printed, as well as data sets requested by the user that must be printed or punched. 
After a job finishes, JES2 analyzes the characteristics of the job’s output in terms of 
its output class and device setup requirements; then JES2 groups data sets with 
similar characteristics. JES2 queues the output for print or punch processing. 


5. Hardcopy phase 


JES2 selects output for processing from the output queues by output class, route code, 
priority, and other criteria. The output queue can have output that is to be processed 
locally or at a remote location. After processing all the output for a particular job, 
JES2 puts the job on the purge queue. 


6. Purge phase 


When all processing for a job completes, JES2 releases the spool space assigned to 
the job, making the space available for allocation to subsequent jobs. JES2 then issues 
a message to the operator indicating that the job has been purged from the system. 


5.16 JES2 compared to JES3 


5-30 


IBM provides two JESs from which to choose: JES2 and JES3. In an installation that has 
only one processor (computer), JES2 and JES3 perform similar functions. That is, they 
read jobs into the system, convert them to internal machine-readable form, select them 
for processing, process their output, and purge them from the system. However, for an 
installation that has more than one processor in a configuration, there are noticeable 
differences between the two, mainly in how JES2 exercises independent control over its 
job processing functions. That is, within the configuration, each JES2 processor controls 
its own job input, job scheduling, and job output processing. In a sysplex environment, it 
is possible to configure JES2 to share spool and checkpoint data sets with other JES2 
systems in the same sysplex. This configuration is called Multi-Access Spool (MAS). 


In contrast, JES3 exercises centralized control over its processing functions through a 
single global JES3 processor. This global processor provides all job selection, 
scheduling, and device allocation functions for all the other JES3 systems. The 
centralized control that JES3 exercises provides increased job scheduling control, 
deadline scheduling capabilities, and increased control by providing its own device 
allocation. 


However, most installations use JES2. 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter5 batch and jcl.fm 


5.17 Summary 


Batch processing is the most fundamental function of z/OS. Many batch jobs are usually 
run in parallel and JCL is used to control the operation of each job. Correct use of JCL 
parameters (especially the DISP parameter in DD statements) allows parallel, 
asynchronous execution of jobs that may need access to the same data sets. 


An initiator is a system program that processes JCL, sets up the necessary environment 
in an address space, and runs a batch job in the same address space. Multiple initiators 
(each in an address space) permit the parallel execution of batch jobs. 


A typical z/OS program uses artificial names (DD names) internally to access data sets. 
A JCL DD statement connects the DD name to a specific data set (DS name) for one 
execution of the program. A program can access different groups of data sets (in different 
jobs) by changing the JCL for each job. Most z/OS functions use JCL. It is explicit for 
batch jobs but may be “under the covers” for other types of usage. 


Basic JCL contains three types of statements: JOB, EXEC, and DD. A job may contain 
several EXEC statements (several steps) and each step may have several DD statements. 
JCL can provide a wide range of parameters and controls; only a basic subset is described 
in this text. 


The DISP parameters of DD statements are used to help prevent unwanted simultaneous 
access to data sets. This is critically important for general system operation. The DISP 
parameter is not a security control, rather it helps manage the integrity of data sets. New 
data sets can be created through JCL by using the DISP=NEW parameter and specifying 
the desired amount of space and the desired volume. 


System users are expected to write simple JCL but normally use JCL procedures for 
more complex jobs. A catalog procedure is written once and can then be used by many 
users. z/OS supplies many JCL procedures, and locally-written ones can be added easily. 
A user must understand how to override or extend statements in a JCL procedure in order 
to supply the parameters (usually DD statements) needed for a specific job. 


A major goal of an operating system is to process jobs while making the best use of 
system resources. To achieve that goal, the operating system does resource management, 
which consists of three steps: before job processing, reserve input and output resources 
for jobs; during job processing, manage resources such as processors and storage, and 
after job processing, free all resources used by the completed jobs, making the resources 
available to other jobs. 


z/OS shares with JES the management of jobs and resources. JES receives jobs into 
z/OS, schedules them for processing by z/OS, and controls their output processing. 


JES is the manager of the jobs waiting in a queue. It manages the priority of the set of 
jobs and their associated input data and output results. The initiator uses the statements in 
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the 


JCL cards to specify the resources required of each individual job once it has been 


released (dispatched) by JES. 


During the life of a job, both JES and the base control program of z/OS control different 
phases of the overall processing. The job queues contain jobs that are waiting to run 
(conversion queue), currently running (execution queue), waiting for their output to be 


pro 


duced (output queue), having their output produced (hard-copy queue) and waiting to 


be purged from the system (purge queue). 











Key terms in this chapter 

alias batch ddname 

JCL JOB EXEC 

jobname stepname system catalog 
DD submit SDSF 

PROC RECFM (record format) System Libraries 








5.18 Discussion questions 
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Thi 


s material is intended to be discussed in class, with the instructor, and these 


discussions should be regarded as part of the basic course text. 


is 
2, 


z/OS Basics 


What are two defining characteristics of z/OS that are discussed in this chapter? 


Why has the advent of data base systems potentially changed the need for large 
numbers of DD statements? 


In the procedure fragment and job in 5.10, “JCL procedures (PROC)” on page 5-14, 
were is the COBOL source code? What is the likely output data set for the 
application? What is the likely input data set? How would we code the JCL for a 
SYSOUT data set for the application? 


How did we know all the DD names needed in the COBOL procedure? 
Why are unique data set names needed by z/OS? 


The first positional parameter of a JOB statement is an accounting field. How 
important is accounting for mainframe usage? Why? 


We have three DD statements: 


//DD1 DD UNIT=3480,... 
//DD2 DD UNIT=0560,... 
//DD3 DD UNIT=560,... 
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10. 
11. 


12. 


13. 


14. 
15. 


16. 
17. 
18. 
19. 


What do these numbers mean? How do we know this? 


The disk volume used for class exercises is WORKO2. Can you allocate a data set on 
other volumes? On any volume? 


JCL can be submitted and started. What is the difference? 
Which JCL statement (JOB, EXEC, or DD) has the most operands? Why? 


What is the difference between JCL and a JCL PROC? What is the benefit of using a 
JCL PROC? 


In order to override a JCL PROC statement in the JCL stream executing the PROC, 
what PROC names must be known? What is the order of the names on the JCL 
override statement? 


When a JCL job has multiple EXEC statements, what is the type of name associated 
with each EXEC statement? 


What special characters are used to identify a temporary data set in a JCL stream? 


What information about a data set is stored in a catalog? What DD operands would be 
required if a data set were not in the catalog? 


What is the difference between the master catalog and a user catalog? 
Why does z/OS need a JES? 
During the life of a job, what processing does JES2 do for z/OS? 


What is the role of JES2 in a online environment? 


5.19 Exercises and demonstrations 


Instructor note: It is best to walk through the exercises and demonstrations together in 
class. After doing this there should be time to experiment a little with exercise variations. 


Also, you may note that this chapter includes a lot of exercises. You may want to use 
them all after discussing this chapter. You can also use them as additional exercises for 
the other chapters. 


5.19.1 Create a simple JCL 


1. 


From ISPF, navigate to the Data Set List Utility panel and enter yourid.JCL in the 
Dsname Level field (described in an earlier exercise). 


Enter e (edit) to the left (in the command column) of yourid.JCL. Enter s (select) to 
the left of member JCLTEST. Enter RESet on the editor command line. 


Notice that only a single JCL line is in the data set, EXEC PGM=IEFBR14. This is a 
system utility that does not request any input or output and is designed to complete 
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with a successful return code (0). Enter SUBMIT or SUB on the command line. Enter 1 
to the message 


IKJ56700A ENTER JOBNAME CHARACTER(S) - 
The result will be the message 
1KJ562501 JOB yourid1(J0B00037) SUBMITTED 
And if the job is finished, you may see the message 
$HASP165 yourid1 ENDED AT SYS1 MAXCC=0 CN(INTERNAL) 


. Replicate (r) the single line and overtype the first JCL statement to read: 


// youridA JOB 1... 
Then submit this JCL and press PF3 to save and exit the editor. 


. From the ISPF Primary Option Menu, find SDSF (described in 3.6.4, “What is 


SDSF?” on page 3-20). You can use the SPLIT screen function for a new Screen 
Session, so you have one session for the Dslist and the other for SDSF. 


. Inthe SDSF menu enter PREFIX yourid*, then enter ST (Status Panel). Both jobs 


submitted should be listed. Place S (select) to the left of either job, then page up and 
down to view the messages produced from the execution. PF3 will exit. 


. Edit JCLTEST again; insert the following line at the bottom: 


//CREATE DD DSN=yourid.MYTEST,DISP=(NEW,CATLG) , 
// UNIT=SYSDA, SPACE=(TRK, 1) 


Submit the content of JCLTEST created above, press PF3 (save and exit edit), then 
view the output of this job using SDSF. Notice you have two jobs with the same 
jobname. The jobname with the highest JOBID number is the last one. 


a. What was the condition code? If it was greater than 0, then page down to the 
bottom of the output listing to locate the JCL error message. Correct the JCLTEST 
and resubmit until cond code=0000 is received. 

b. Navigate to the Data Set List Utility panel (=3.4) and enter yourid:MYTEST in 
the Dsname Level field. What volume was used to store the data set? 

c. Enter DEL / to the left (command column) of the data set to delete the data set. A 
confirmation message may appear asking you to confirm that you want to delete 
the data set. 

d. We just learned that JCL execution of program IEFBR14, which requires no 
inputs or outputs, returns a condition code 0 (success), provided no JCL errors. 
Although IEFBR14 does no I/O, JCL instructions are read and executed by the 
system. This program is useful for creating and deleting data sets by specifying 
DSN and DISP=(0LD,DELETE) on a DD statement. 


. From any ISPF panel, enter in the Command Field ==> 


TSO SUBMIT JCL(JCLERROR) 


Your userid is the assumed prefix of data set JCL containing member JCLERROR. 
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10. 


11. 


1 


N 


a. You will be prompted to enter a suffix character for a generated job card. Take 
note of the jobname and job number from the submit messages. 

b. Use SDSF and select the job output. Page down to the bottom. Do you see the 
JCL error? What are the incorrect and correct JCL DD operands? Correct the JCL 
error located in yourid.JCL(JCLERROR). Resubmit JCLERROR to validate your 
correction. 


From any ISPF panel, enter TSO SUBMIT JCL(SORT). Your userid is the assumed 
prefix of data set JCL containing member SORT. 


a. You will be prompted to enter a suffix character for a generated job card. Take 
note of the jobname and job number from the submit messages. 

b. Use SDSF and place a ? to the left of the job name. The individual listing from the 
job will be displayed. Place s (select) to the left of SORTOUT to view the sort 
output, then press PF3 to return. Select JESJCL. Notice the “job statement 
generated message” and the “substitution JCL” messages. 


Let’s purge some (if not all) unnecessary job output. From SDSF, place a p (purge) to 
the left of any job that you would like to purge from the JES output queue. 


. From the ISPF panel, enter TSO SUBMIT JCL(SORT), then review the output. 
. From the ISPF panel, enter TSO SUBMIT JCL(SORTPROC), then review the output. 


You may not see the output in the SDSF ST panel. This is because the jobname is not 
starting with yourid. To see all output, enter PRE *, then enter OWNER yourid to see 
only the jobs that are owned by you. 


. What JCL differences exist between SORT and SORTPROC? In both JCL streams, the 


SYSIN DD statement references the sort control statement. Where is the sort control 
statement located? 


Tip: All JCL references to &SYSUID are replaced with the userid that submitted 
the job. 


. Edit the partitioned data set member containing the SORT control statement. Change 


FIELD=(1,3,CH,A) to FIELD=(6,20,CH,A). Press PF3 and then from the ISPF 
panel enter TSO SUBMIT JCL(SORT). Review the job’s output using SDSF. Was this 
sorted by code or area? 


. From the ISPF panel, enter TSO LISTC ALL. By default, this will list all catalog 


entries for data sets beginning with yourid. The system catalog will return the data set 
names, the name of the catalog storing the detailed information, the volume location, 
and a devtype number that equates to specific values for JCL UNIT= operand. LISTC 
is an abbreviation for LISTCAT. 
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5.19.2 ISPF split screen 


As discussed earlier, most ISPF users favor a split screen. This is easily done: 

1. Move the cursor to the bottom (or top) line. 

2. Press PF2 to split the screen. 

3. Press PF9 to switch between the two screens. 

4. Use PF3 (perhaps several times) to exit from one of the splits. 

The screen need not be split at the top or bottom. The split line can be positioned on any 
line by using PF2. 

More than two screens can be used. Try to use the ISPF commands: 


START 
SWAP LIST 
SWAP <screen number.> 


5.19.3 Submit jobs, check results - COBOL example 


5-36 


Edit member COBOL1 in yourid.LIB.SOURCE library and inspect the COBOL 
program. Notice that there is no JCL with it. Now edit member COBOL] in yourid.JCL.’ 


Inspect the JCL carefully. It uses a JCL procedure to compile and run a COBOL 


program.® 


Take these steps: 

1. Change the job name to yourid plus additional characters. 
2. Change the NOTIFY parameter to your userid. 

3. Type SUB on the ISPF command line to submit the job. 

4 


Split your ISPF screen and go to SDSF on the new screen (if not already available 
from a earlier exercise). 


5. In SDSF go to the ST (Status) display and look for your job name. 


You may need to enter a PRE or OWNER command on the SDSF command line to 
see any job names. (An earlier user may have set a prefix parameter to see only 
certain job names.) 


6. Type S beside your job name to see all of the printed output: 


— Messages from JES2 
— Messages from the initiator 
— Messages from the COBOL compiler 


7 The matching member names (COBOL1) are not required; however, they are convenient. 
This is not exactly the COBOL procedure we discussed earlier. Details of these procedures sometimes change 
from release to release of the operating system. 
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— Messages from the binder 
— Output from the COBOL program 


7. Use PF3 to “move up” a level and type ? beside your job name to display another 
output format. 


The instructor will briefly describe the purposes of the various JES2 and initiator 
messages. 


> Resubmit the job with MSGLEVEL=(1,1) on the JOB statement. 
> Resubmit the job with MSGLEVEL=(0,0) on the JOB statement. 


The MSGLEVEL parameter controls the number of initiator messages that are produced. 


5.19.4 Create a new PDS member 


There are several ways to create a new PDS member. Try each of the following, using 
your own userid. In the following steps, TEST3, TEST4, TESTS, and TEST6 represent 
new member names. Enter a few lines of text in each case. 


Use the ISPF edit panel: 


> Go to the ISPF primary menu. 

> Go to option 2 (Edit). 

> Inthe Data Set Name line, enter JCL(TEST3) (no quotes!) 
> Enter a few text lines and use PF3 to save the new member. 


A new member can be created while viewing the member list in edit mode: 


> Use option 3.4 (or option 2) to edit yourid.JCL. 
> While viewing the member list, enter S TEST4 in the command line. 
> Enter a few text lines and use PF3 to save the new member. 


A new member can be created while editing an existing member: 


> Edit yourid.JCL(TEST1) or any other existing member. 

> Select a block of lines be entering cc (in the line command area) in the first and last 
lines of the block. 

> Enter CREATE TEST5 on the command line. This will create member TESTS in the 
current library. 


A new member can be created with JCL. Enter the following JCL in yourid.JCL(TESTS) 
or any other convenient location: 


//yourid1 JOB 1,JOE,MSGCLASS=X 

//STEP1 EXEC PGM=IEBGENER 

//SYSIN DD. DUMMY 

//SYSPRINT DD SYSOUT=* 

//SYSUT2 DD DISP=OLD,DSN= yourid.JCL (TEST6) 
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//SYSUT1 DD * 

This is some text to put in the member 
More text 

/* 


Save the member with this JCL. It will be used later. 


5.19.5 Copy a PDS member (demonstration or optional exercise) 


There are many ways to copy a library member. An earlier exercise used the ISPF 3.3 
function to copy all the members of a library. The same function can be used to copy one 
or more members. 


While editing a library member, we can copy another member into the member being 
edited: 


> Edit a library member. 

> Mark a line in this member with a (after) or b (before) to indicate where the other 
member should be copied. 

> Enter COPY xxx on the command line, where xxx is the name of another member in 
the current data set. 


We can copy a member from another data set (or a sequential data set) as follows: 


Edit a member or sequential data set. 

Mark a line with a (after) or b (before) to indicate where to insert the new material. 
Enter COPY on the command line. This will produce an Edit/View-Copy panel. 
Enter the full sequential data set name (with single quotes, if necessary) or a full 
library+member name in the Data Set Name field. 


vvvy 


5.19.6 Inspect system volumes (demonstration or optional exercise) 
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The instructor (or each student) can use the ISPF functions to explore several system 
volumes. The following are of interest: 


> Examine the naming of VSAM data sets. Note the names DATA and INDEX as the 
last qualifier. 

> Find the spool area. This may involve a guess based on the data set name. How large 
is it? 

> Find the basic system libraries, such as SYS1.PROCLIB and so forth. Look at the 
member names. 

> Consider the ISPF statistics field that is displayed in a member list. How does it differ 
for source libraries and execution libraries? 
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5.19.7 PA1 key 


The “real” 3270 terminals had keys labeled PA1, PA2, and PA3. These were Program 
Action keys. In practice, only PAI is widely used and it functions as a break key for TSO. 
In TSO terminology, this is an attention interrupt. That is, it will terminate a current 
task. Finding the PA1 key on the keyboard of a TN3270 emulator may be a challenge. It 
can be customized to many different key combinations. (On an unmodified x3270 
session, it is Left Alt-1.) 


This is a very important key for TSO users and every user should know how to find it on 
his/her keyboard. 


As an example, try the following: 


Go to ISPF option 6. This panel accepts TSO commands. 

Enter LISTC LEVEL(SYS1) ALL on the command line (and press Enter). 

This should produce a screen of output with *** in the last line on the screen. 

The *** indicates that there is more output waiting and the user must press Enter to 

see the next screen. (This meaning is consistent in almost all TSO usage.) 

> Press Enter for the next screen, and press Enter for the next screen, and so forth. This 
command produces lots of output, although it is not an endless loop. 

> Press the PAI key, using whatever key combination is appropriate for your TN3270 

emulator. This should terminate the output. 


vvvy 


5.19.8 Write a complete job 


We have a utility program named IEBGENER. It uses four DD statements: 


> SYSIN for control statements. We can use a DD DUMMY for this statement. 
> SYSPRINT for messages from the program. Use SYSOUT=xX for this. 

> SYSUT1 for input data. 

> SYSUT2 for output data. 


The basic function of the program is to copy the data set pointed to by SYSUT1 to the 
data set pointed to by SYSUT2. Both must be sequential data sets (or specific members 
of a library). 


The program automatically obtains the DCB attributes from the input data set and applies 
them to the output data set. Write the JCL for a job to list the yourid.JCL(TEST1) 
member on SYSOUT=X. 


5.19.9 Inspect TSO logon JCL 


The password panel of the TSO logon process contains the name of the JCL procedure 
used to create a TSO session. There are several procedures with different characteristics. 
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Look at the ISPFPROC procedure. The instructor can help find the correct library for 
ISPFPROC. 


> What is the name of the basic TSO program that is executed? 
> Why are there so many DD statements? Notice the concatenation. 


Look for procedure IKJACCNT. This is a minimal TSO logon procedure. 


5.19.10 Explore the master catalog 
Go to ISPF option 6 and do the following: 


> Usea LISTC LEVEL(SYS1) command for a basic listing of all the SYS1 data sets in 
the master catalog. 

> Notice that they are either NONVASM or CLUSTER (and associated DATA and 
INDEX entries). The CLUSTERS are for VSAM data sets. 

> Use PAI to end the listing. 

> UseaLISTC LEVEL(SYS1) ALL command for a more extended listing. 


Note the volser and device type data for the NONVSAM data sets. This is the basic 


information in the catalog. 


The instructor has a slightly different TSO environment (with NOPREFIX in the profile). 
He can use the commands LISTC and LISTC ALL to see all of the master catalog 
including ALIAS entries. Use LISTC _LEVEL(xxx) to view one of the ALIAS levels and 
note that it comes from a user catalog. 


5.20 Exercise 


1. Using the ISPF panel, SUBMIT the Job HELLO in yourid.LIB.SOURCE. 
2. Split your ISPF screen and go to SDSF on the new screen. 
3. Check SDSF for the job status 
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5.21 Instructor Notes 


Chapter introduction 


This chapter described how to execute applications that have been previously developed 
and are catalogued (saved) in the system libraries (see 5.13, “System libraries” on 
page 5-20). Subsequent chapters will discuss how new applications are developed, and, 
when complete, are cataloged in the system libraries for later execution. 


A z/OS application is called a job, and Job Control Language or Job Statements are used 
to describe certain attributes of the job to z/OS. The initiator is an integral part of z/OS 
that reads, interprets, and executes the JCL. 


JES is a SPOOLing program (Simultaneous Peripheral Output Operations On-Line). Its 
purpose is to manage the input and output job queues and data. Describe the history of 
SPOOLing: How a single unit record equipment (card reader, punch, printer) was shared 
among initiators, and a utility program was supplied to associate the input and output to 
the appropriate initiator. If a job required reading of input data from an external unit 
record device (such as a card reader) and produced printed output, the initiator managed 
the queues and data. 


Refer to 5.2, “Job flow” on page 5-3 


There is some debate about the origin of the term spool. It was associated with 
Simultaneous Peripheral Operation On Line by some IBM systems prior to S/360, but 
this phrase may have been backfitted to the word. The earlier mainframes (IBM 7090 and 
similar systems) typically had their input (in card image form) written on tape by a 
smaller computer. The large system wrote printed output to tape and the output tapes 
were moved to a smaller system for actual printing. This was efficient because the large 
systems operated at tape speed instead of card reader/printer speed. 


Card readers, printers, and card punches are collectively known as unit record devices. 


Refer to 5.4, “Symbolic file system” on page 5-4 


Explain that we use symbolic file ID’s to provide program independence from the actual 
physical device that has the data. 


The indirect naming of data sets to be used by a program may seem awkward, and 
alternate techniques are more convenient for programs that work with only a few data 
sets. OS/360 was designed primarily to work with large commercial applications and this 
design has been carried through all the versions of the operating system. These 
applications usually involve many data sets during execution, although the advent of data 
base systems has somewhat changed this characteristic. 
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Refer to 5.6.1, “JOB operands” on page 5-8 


The first line of the JOB1 member is the JOB statement. It specifies parameters to be 
used by the job entry subsystem to schedule this job for processing. The format of the 
JOB card, and the importance of the data specified on it vary from installation to 
installation. The following fields are important: 


Jobname The first field is the jobname. It can have up to eight characters. 
Some sites perform security checking against the jobname to 
ensure standards, usually the ID of the user who submitted the job. 
Let us suppose the standard is: user ID suffixed with at least one 
alphanumeric character. 

JOB Identifies the job to the system, when submitted. It must be present, 
must follow the jobname and there must be at least one space 
between them. 

Account Some sites use this field for accounting and job processing 
information. In the example, the value is 19. 

Programmer name The next field is the programmer name field, which you can use to 
identify the member name, for example. 

Notify Tells the system where to send “job complete” information. 
&SYSUID tells the system to automatically insert your user ID here, 
so the information will be sent to you. 


Msgclass class MSGCLASS= assigns the job log to an output class. The output class 
and its characteristics are identified in a parameter file used at JES 
initialization. 

Msglevel Tells the system to reproduce this JCL code in the output, and to 
include allocation messages. 

Job class The CLASS= field identifies the JES job class this job will execute 


under. In the example, CLASS=A is the JES job class. Many sites do 
not use this option, and the JES class is set according to your user 
ID. Job classes are set up at JES initialization. 


Refer to 5.6.2, “EXEC operands” on page 5-9 


The EXEC Statement identifies the step and the program to be executed. In our job, we 
have just one step, arbitrarily identified by the name STEP1, and we invoke the IEFBR14 
program. This program comes in all installations and it does nothing, just receives the 
control and gives it back to the system; that’s why it is good for using some JCL 
capabilities. 


On the EXEC statement you specify: 


Step name —__In the example STEP1 gives a name to the step. You could have called the 
step IEFBR14, or any name that will help you identify the step. In a large 
job, with many steps, unique step names can assist you when diagnosing 
problems. The choice is yours. 

EXEC Identifies a step job. It must be present. 
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PGM= Specifies the name of the program to be executed. In this case the 
program name is IEFBR14. 


Two other parameters that you might use on the EXEC statement are: 


> The REGION parameter specifies the amount of virtual storage (or central storage 
when ADDRSPC=REAL is coded) that a step requires. If no REGION parameter is 
specified, the system uses an installation default specified at system initialization. 


A program might need more storage than is allowed by default. To permit the 
program to get more storage, you can code the REGION parameter as follows: 


//STEP1 EXEC PGM=progname , REGION=4096K. 


This permits the program to get up to 4 MB of storage below 16 MB and up to the 
installation default storage above 16 MB (for example, 32 MB). 


> The COND parameter is used to test return codes from previous job steps and 
determine whether to bypass the current job step. You can specify one or more tests 
on the COND parameter, and you can test return codes from particular job steps or 
from every job step that has completed processing. If any of the test conditions are 
satisfied, the system evaluates the COND parameter as true and bypasses the job step. 
If none of the test conditions specified on the COND parameter are satisfied, the 
system evaluates the COND parameter as false and executes the job step. 


The system performs the COND parameter tests against return codes from the current 
execution of the job. If a test specifies a previous step that was bypassed, the system 
evaluates the COND parameter as false. 


For example: 
//STEP6 EXEC PGM=DISKUTIL, COND=(4,GT,STEP3) 


With this statement, if the return code from STEP3 is 0 through 3, the system 
bypasses STEP6. If the return code is 4 or G7 (greater than), the system executes 
STEP6. You could also check for return codes that are EQual to, LT (less than), GE 
(greater than or equal to), and LE (less than or equal to). 


Refer to 5.6.3, “DD operands” on page 5-9 

DSN= The name of the data set. This can include creation of temporary data sets or a 

reference back to a data set name or temporary data set from a previous step. 

> //TEMP DD DSN=&&TEMPDSN - is a temporary data set only available during the life of 
the job, which can be referenced by subsequent steps in the job. 

> //READ DD DSN=*.stepname. TEMP - refers back to the //TEMP temporary data set 
which can be read by the current job step in execution. 


> Provided DISP=(NEW,PASS,PASS) was coded with DSN=&&TEMPDSN, then //READ DD 
DSN=&&TEMPDSN is an acceptable method for reading the temporary data created in a 
previous job step 
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Refer to 5.7, “Data set disposition, DISP operand” on page 5-10 


z/OS uses the term enqueuing instead of locking to denote any form of usage serialization 
of a resource, such as a data set. The serialization may be exclusive or shared. 


Refer to “Submit JCL to background for batch processing” on 
page 5-16 


Note that it is also possible to use FTP to submit a job to a z/OS system for processing. 
This is very useful, although frequently restricted (check with your system programmer). 
Here is an example how it might be done: 

1. After entering the userid/password, enter quote site filetype=jes 


2. To submit the job, enter put ‘filename’, specifying an ASCII text file that contains 
the job JCL (remember, the source must be uppercase) into the system JCL reader for 
batch execution. 
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z/OS UNIX overview 








> 


> 
> 
> 








Objective: In working with z/OS, you will need to how the most important 
aspects of the z/OS implementation of UNIX interfaces, known collectively as 
z/OS UNIX System Services, or z/OS UNIX for short. 


In this chapter, you will learn: 


An overview of the UNIX interfaces provided on z/OS 
Components of z/OS that allow it to support UNIX workloads 
How to use the z/OS UNIX command shell 

To understand the file and hierarchical file system structure and the 
difference from the z/OS data set and catalog structure 











6.1 z/OS UNIX components 


z/OS provides traditional MVS programming services, plus z/OS UNIX, the UNIX shell 
and utilities feature, IBM Language Environment for z/OS and VM, and C/C++ for the 
z/OS compiler. ! 


' The use of Language Environment, C, and C++ is discussed in Chapter 9, “Using programming languages on 
z/OS” . 
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Figure 6-1 UNIX applications 


The services that support UNIX application programming make it possible to develop 
and run C application programs that provide XPG4.2-defined functions. The C program 
source can be developed on a z/OS system using z/OS UNIX, or on a programmable 
workstation (PWS). Creation of an application executable file must be done using z/OS 
UNIX through the shell. 


z/OS UNIX meets open system requirements. There are thousands of UNIX-based 
applications available today. These applications, which conform to XPG4 standards, can 
be ported to z/OS. These can be vendor applications or self-developed applications. 


Not all applications are meant for z/OS, but an application should be considered for z/OS 
if it requires: 


Large DASD capacity 

Access to high-speed printers 

Support for a larger number of users than traditionally on a LAN 
Shared applications 

High reliability 

Large batch jobs 

High security 


vvvvvvy 


A benefit of z/OS UNIX is scalability. Resources like DASDs, CP power, CPC storage, 
network and peripherals can be scaled up for a UNIX system. 
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6.2 z/OS UNIX shell 


The shell is the interactive interface to z/OS UNIX. The shell is part of the z/OS UNIX 
base element of z/OS. Although some functions can be performed by TSO/E, it is 
recommended that you use the shell. 


To perform some command requests, the shell calls other programs, known as utilities. 
The shell can be used to: 


> Invoke shell scripts and utilities. 

> Write shell scripts (a named list of shell commands, using the shell programming 
language). 

> Run shell scripts and C language programs interactively, in the TSO background or in 
batch. 





z/OS 





z/OS UNIX 
Commands and 
TSO/E Utilities 





OMVS a> Shell —— 











VTAM TCP/IP 














ue n/|7 


Network 





TSO Logon 


ISHELL OMVS a 














Figure 6-2. Shell and utilities 


A user can invoke the shell in the following ways: 


> Through TSO/E from 3270 displays or workstations using 3270 emulators. (The 
workstations can attach to z/OS UNIX via SNA or TCP/IP networks.) 


> From a TCP/IP-attached terminal, using rlogin and telnet commands. 
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> By invoking the shell from TSO/E by issuing the OMVS command or via the 
ISHELL command. 


6.2.1 z/OS UNIX interactive interfaces 


6-4 


Figure 6-3 shows an overview of the two interactive interfaces, the z/OS UNIX shell and 
the ISHELL command. In addition, there are some TSO/E commands to support z/OS 
UNIX, but they are limited to certain functions such as copying files and creating 
directories. 





z/OS UNIX ISPF Shell 
(z/OS Shell) (ISHELL) 
OMVS command ishell command 


filename 
bin 





e UNIX interface e ISPF based 
e POSIX 1003.2 e Menu interface 
e Command interface 
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Figure 6-3 z/OS UNIX interactive interfaces 


The z/OS UNIX shell is based on the UNIX System V shell and has some of the features 
from the UNIX Korn shell. The POSIX standard distinguishes between a command, 
which is a directive to the shell to perform a specific task, and a utility, which is the name 
of a program callable by name from the shell. To the user, there is no difference between 
a command and a utility. 


The z/OS UNIX shell provides the environment that has the most functions and 
capabilities. Shell commands can easily be combined in pipes or shell scripts and thereby 
become powerful new functions. A sequence of shell commands can be stored in a text 
file that can be executed. This is called a shell script. The shell supports many of the 
features of a regular programming language. 
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The TSO commands that provide support for z/OS UNIX are: 


ISHELL = The ISHELL command invokes the ISPF shell. ISHELL is a good starting 
point for users familiar with TSO and ISPF who want or need to use z/OS 
UNIX. ISHELL provides panels where users can work with the hierarchical 
file system. There are also panels for mounting and unmounting file systems 
and for doing some z/OS UNIX administration. 


Programmers whose primary interactive computing environment is TSO/E 
and ISPF can do much of their work in that environment. 


OMVS The OMVS command is used to invoke the z/OS UNIX shell. 


An interactive user who uses the OMVS command to access the shell can 
switch back and forth between the shell and TSO/E. 


Programmers whose primary interactive computing environment is a UNIX 
or AIX workstation find the z/OS UNIX shell programming environment 
familiar. 


6.2.2 ISHELL command (ish) 


Figure 6-4 shows the ISHELL or ISPF Shell panel displayed as a result of the ISHELL or 
ISH command being entered from ISPF Option 6. 





File Directory Special file Tools File systems Options Setup Help 


UNIX System Services ISPF Shell 
Enter a pathname and do one of these: 


- Press Enter. 
- Select an action bar choice. 
- Specify an action code or command on the command line. 


Return to this panel to work with a different pathname. 
More: ee 
/u/rogers 























Figure 6-4 Panel displayed after issuing the ISH command 


6.2.3 ISHELL - user files and directories 


To search a user's files and directories, type the following and press Enter: 
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/u/userid 





Directory List 


Select one or more files with / or action codes. If / is used also select an 
action from the action bar otherwise your default action will be used. Select 
with S to use your default action. Cursor select can also be used for quick 
navigation. See help for details. 

EUID=0 /u/rogers/ 


Type Perm Changed-EST5EDT Owner  ------ Size Filename Row 1 of 9 
_ Dir 700 2002-08-01 10:51 ADMIN 8192 
_ Dir 555 2003-02-13 11:14 AAAAAAA O! sa 
_ File 755 1996-02-29 18:02 ADMIN 979 .profile 
_ File 600 1996-03-01 10:29 ADMIN 29 .sh_history 
_ Dir 755 2001-06-25 17:43 AAAAAAA 8192 data 
_ File 644 2001-06-26 11:27 AAAAAAA 47848 inventory.export 
_ File 700 2002-08-01 10:51 AAAAAAA 16 myfile 
_ File 644 2001-06-22 17:53 AAAAAAA 43387 print.export 
_ File 644 2001-02-22 18:03 AAAAAAA 84543 Sc.pdf 











Figure 6-5 Display of a user's files and directories 


Shown in Figure 6-5 are the files and directories of user rogers. The user can then use 
action codes to do the following: 


Browse a file or directory 

Edit a file or directory 

Delete a file or directory 

Rename a file or directory 

Show the attributes of a file or directory 
Copy a file or directory 


aonr aw oe 


6.2.4 OMVS command shell session 
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Use the OMVS command to invoke the z/OS UNIX shell. 


Shell commands often have options (also known as flags) that you can specify, and they 
usually take an argument, such as the name of a file or directory. The format for 
specifying the command begins with the command name, then the option or options, and 
finally the argument, if any. 

In Figure 6-6 the following command is shown: 


1s -al /u/rogers 


where 1s is the command name, and -al are the options. 
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ROGERS @ SC43:/>ls -al /u/rogers 

total 408 

drwx------ 3 ADMIN sysl1 8192 Aug 1 2002 . 

dr-xr-xr-x 93 AAAAAAA TTY 0 Feb 13 11:14 .. 
-Ywxr-xr-x 1 ADMIN SYS1 979 Feb 29 1996 .profile 
-Iw------- 1 ADMIN SYS1 29 Mar 1 1996 .sh history 
-rw-r--r-- 1 AAAAAAA SyYS1 84543 Feb 22 2001 Sc.pdf 
drwxr-xr-x 2 AAAAAAA SYS1 8192 Jun 25 2001 data 
-rw-r--r-- 1 AAAAAAA SyYS1 47848 Jun 26 2001 inventory.export 
-Iwx------ 1 AAAAAAA $SYS1 16 Aug 1 2002 myfile 
-rw-r--r-- 1 AAAAAAA SyYS1 43387 Jun 22 2001 print.export 











Figure 6-6 OMVS shell session display after issuing the OMVS command 


This command lists the files and directories of the user. If the pathname is a file, 1s 
displays information on the file according to the requested options. If it is a directory, 1s 
displays information on the files and subdirectories therein. You can get information on a 
directory itself by using the -d option. 

The shell is a command processor that you use to: 

> Invoke shell commands or utilities that request services from the system. 

> Write shell scripts using the shell programming language. 

> Run shell scripts and C-language programs interactively (in the foreground), in the 


background, or in batch. 


If you do not specify any options, 1s displays only the file names. When 1s sends output 
to a pipe or file, it writes one name per line; when it sends output to the terminal, it uses 
the -C (multicolumn) format. 
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Figure 6-7 Diagram of a login to the shell from a terminal workstation 


A z/OS UNIX user can log in directly to the z/OS UNIX shell using one of the following 

solutions: 

rlogin When the inetd daemon is set up and active, you can rlogin to the shell from 
a workstation that has rlogin client support and is connected through TCP/IP 
or Communications Server to the z/OS system. To log in, use the rlogin 
(remote log in) command syntax supported at your site. 

telnet The telnet support comes with the TCP/IP z/OS UNIX feature. It also uses 
the inetd daemon, which must be active and set up to recognize and receive 
the incoming telnet requests. 


Figure 6-8 shows the z/OS shell after being entered from a telnet login. 


ics 
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Bette acon Fat a aLxy 


Connect Edit Terminal Help 
(C) Copyright Software Development Group, University of Waterloo, 1989. 


All Rights Reserved. 


U.S. Government users - RESTRICTED RIGHTS - Use, Duplication, or 
Disclosure restricted by GSA-ADP schedule contract with IBM Corp. 


IBM is a registered trademark of the IBM Corp. 


- Improve performance by preventing the propagation - 
- of TSO/E or ISPF STEPLIBs ot 


CLASSPATH reset to .:/usr/lpp/Java/J1.1/lib/classes.zip:/usr/lpp/internet/server 
_root/cgi-bin/icsclass.zip:/usr/lpp/internet/server_root/servlets/public: /u/suf/ 
classes 


ROGERS @ SC47:/>ff 





Figure 6-8 Telnet login to the shell screen 


There are some differences between the asynchronous terminal support (direct shell 
login) and the 3270 terminal support (OMVS command): 


> You cannot switch to TSO/E. However, you can use the TSO SHELL command to 


run a TSO/E command from your shell session. 
> You cannot use the ISPF editor (this includes the oedit and TSO/E OEDIT 


commands, which invoke ISPF edit). 


6.3 Hierarchical file system (HFS) 


A z/OS UNIX file system is hierarchical and byte-oriented. Finding a file in the file 
system is done by searching a directory or a series of directories. There is no concept of a 
z/OS catalog that points directly to a file. 
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Figure 6-9 Hierarchical file system structure 


A path name identifies a file and consists of directory names and a file name. A fully 
qualified file name, which consists of the name of each directory in the path to a file plus 
the file name itself, can be up to 1023 bytes long. The hierarchical file system allows for 
file names in mixed case. 


The path name is constructed of individual directory names and a file name separated by 
the forward-slash character, for example: 


/dir1/dir2/dir3/myfile 


Like UNIX, z/OS UNIX is case-sensitive for file and directory names. For example, in 
the same directory, the file MYFILE is a different file than myfile. 


The files in the hierarchical file system are sequential files, and are accessed as byte 
streams. A record concept does not exist with these files other than the structure defined 
by an application. 


The hierarchical file system (HFS) data set which contains the hierarchical file system is 
a z/OS data set type. 


HFS data sets and z/OS data sets can reside on the same DASD volume. 


The integration of the HFS file system with existing z/OS file system management 
services provides automated file system management capabilities that may not be 
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available on other UNIX platforms. This allows file owners to spend less time on tasks 
such as backup and restore of entire file systems. 


6.3.1 z/OS data sets versus file system files 





z/OS UNIX System Services 
MASTER CATALOG «—__» ROOT 
ALIAS IBMUSER / 
USER <=____ » USER DIRECTORY 
CATALOG /u/ibmuser 
DSN=IBMUSER.C <_<» /u/ibmuser/c/ 
PDS 
DSN=IBMUSER.C(PGMA) <> /u/ibmuser/c/pgma 
/u/ibmuser 
FILE1 2 FILE5 ; : 
SEQ PDS VSAM file1 a file5 
FILE3 file3 filed 
FILE4 
RECFM BLKSIZE Sa ane provided 
; : y the application 


TYPE OF DATA SET 











Figure 6-10 Comparison of z/OS data sets and file system files 
The z/OS master catalog is analogous to the root directory in a hierarchical file system. 


The user prefix assigned to z/OS data sets points to a user catalog. The organization of 
the user catalog is analogous to a user directory (/u/ibmuser) in the file system. Typically, 
one user owns all the data sets whose names begin with his user prefix. For example, the 
data sets belonging to the TSO/E user ID IBMUSER all begin with the prefix IBMUSER. 
There could be data sets named IBMUSER.C, and IBMUSER.C(PGMA). 


In the file system, ibmuser would have a user directory named /u/ibmuser. Under that 
directory there could be a subdirectory named /u/ibmuser/c, and /u/ibmuser/c/pgma 
would point to the file pgma. 


Of the various types of z/OS data sets, a partitioned data set (PDS) is most like a user 
directory in the file system. In a partitioned data set such as IBMUSER.C, you could 
have members PGMA, PGMB, and so on. For example, you could have 
IBMUSER.C(PGMA) and IBMUSER.C(PGMB). A subdirectory such as /u/ibmuser/c 
can hold many files, such as pgma, pgmb, and so on. 
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All data written to the hierarchical file system can be read by all programs as soon as it is 
written. Data is written to a disk when a program issues an fsync(). 


6.4 z/OS UNIX programs (processes) 


6-12 


A process is a program using 


kernel services. The program can be created by a fork() 


function, fork callable service, or spawn() function; or the program can be dubbed 
because it requested kernel services. 
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Figure 6-11 2/OS UNIX programs (processes) and components 


The three types of processes are: 
User processes These are associated with a program or a shell user. 


Daemon processes 
such as printer spooling. 


Kernel processes 
cleaning up zombie processes (init process). 


These perform continuous or periodic system-wide functions, 


These perform system-wide functions for the kernel, such as 


When you enter a shell command, you start a process that runs in a z/OS address space. 


When you enter that command, 


it is considered a separate job 


the z/OS shell runs it in its own process group. As such, 
and the shell assigns it a job identifier—a small number 


known only to the shell. A shell job identifier identifies a shell job, not a z/OS job. When 
the process completes, the system displays the shell prompt. 
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A UNIX program running in a z/OS address space can use or access the following: 
ASM/C++/C These programming languages can be used to create the programs. 


SAF A security access facility (SAF) product is required when running 
UNIX System Services. SAF is the interface to RACF or other SAF 
products. 


BPXPRMxx = This PARMLIB member determines the number of processes that may 
be started in the z/OS system. 


z/OS data sets UNIX programs can access z/OS data sets. 
HFS files UNIX programs can access HFS files. 


TCP/IP Workstation users can enter the shell environment by using rlogin or 
telnet in a TCP/IP network. User-written applications can use TCP/IP 
as a communication vehicle. 


VTAM Workstation users can access TSO/E through Virtual 
Telecommunication Access Method (VTAM). z/OS UNIX is then 
accessed from TSO/E. 


6.5 The BPXBATCH utility 


BPXBATCH is a z/OS utility that you can use to run shell commands or shell scripts and 
to run executable files through the z/OS batch environment. You can invoke BPXBATCH 
as follows: 


> InJCL 
> From the TSO/E READY prompt 
> From TSO CLISTs and REXX execs 


> From a program 
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S1 EXEC PGM=MVSPROG1 MVS batch program 


S2 EXEC CPGM=BPXBATCH z/OS UNIX batch 
/!_ PARM='pgm cprog a1 a2’ program 


S3 EXEC PGM=MVSPROG2 


MVS batch program 


End of job 














Figure 6-12 JCL used when using the BPXBATCH utility 


BPXBATCH has logic in it to detect when it is run from JCL. If the BPXBATCH 
program is running as the only program on the job step task level, it sets up the stdin, 
stdout, and stderr files and execs the requested program. If BPXBATCH is not running as 
the only program at the job step task level, the requested program will run as the second 
step of a JES batch address space from JCL in batch. 


Example 6-1 Sample JCL for a BPXBATCH job 


//OMVSPGM JOB  USER=userid 
//OMVSEXEC EXEC PGM=BPXBATCH,PARM='pgm cprog al a2' 
//STDOUT DD PATH='/dirl/dir2/std.output', 


// PATHOPTS=(OWRONLY,OCREATE) , 
i PATHMODE=(SIRWXV) , 

// PATHDISP=KEEP 

//STDERR DD PATH='/dirl/dir2/std.error', 
// PATHOPTS=(OWRONLY,OCREATE) , 
// PATHMODE=(SIRWXV) , 

// PATHDISP=KEEP 

/* 


With BPXBATCH, you can allocate the z/OS standard files stdin, stdout, and stderr as 
HFS files for passing input. If you do allocate these files, they must be HFS files. You can 
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also allocate z/OS data sets or HFS text files containing environment variables (stdenv). 
If you do not allocate them, stdin, stdout, stderr, and stdenv default to /dev/null. Allocate 
the standard files using the data definition PATH keyword options, or standard data 
definition options for z/OS data sets. 


For BPXBATCH, you can define stdin, stdout, and stderr using one of the following: 


> The TSO/E ALLOCATE command, using the ddnames STDIN, STDOUT, and 
STDERR. 


> AJCL DD statement with the PATH operand, using the ddnames STDIN, STDOUT, 
and STDERR. 


> Redirection. 


6.6 Summary 


z/OS UNIX provides an industry standard application interface. Application developers 
and interactive users using the UNIX interfaces have the underlying resources and power 
of the z/OS system available without needing to understand the proprietary interface of 
the z/OS system. 


All the human-intensive factors like the operation, installation, maintenance and systems 
management for separate UNIX servers are not necessary. 


The z/OS UNIX shell and utilities are the interactive interface for end users. They 
provide a command interface to the z/OS UNIX environment. You get access to the shell 
by either logging on to TSO/E or by using the remote login facilities of TCP/IP (rlogin). 
If you use TSO/E, then a command called OMVS will create a shell for you. You then 
work within the shell environment until exiting or temporarily switching back to the 
TSO/E environment. 


A file in the hierarchical file system can be either a text or a binary file. In a text file each 
line of text is separated by a newline delimiter. A binary file consists of sequences of 
binary words (byte stream), and no record concept other than the structure defined by an 
application exists. An application reading the file is responsible for interpreting the 
format of the data. 


z/OS views an entire file system hierarchy as a collection of HFS data sets. Each HFS 
data set is a mountable file system. 
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6.7 Discussion questions 


1. Could you name some of the major z/OS UNIX components? 


2. Is it possible to write a program which uses both standard z/OS services and z/OS 
UNIX? Would this be a portable program? 


Explain the difference between a logical file system and a physical file system. 

Do UNIX processes execute in z/OS address spaces? 

If the students already have UNIX knowledge, what is ASID, PID, PPID, and PGID? 
Can an HFS data set span DASD volumes? 


SD ee ey 


Name the two z/OS UNIX interactive interfaces and explain some of the differences 
between the two. 


8. What is BPXBATCH? 


6.8 Demonstrations and exercises 


To begin, log on to the lab system with your user ID, and perform the exercises in this 
section, which help you explore different aspects of z/OS UNIX. 


6.8.1 OMVS commands 


Enter the z/OS UNIX environment by entering the OMVS command from ISPF, Option 
6. Make sure you are in your home directory. 


Enter the following shell commands 


id Shows your current id. 

date Shows time and date. 

man date Manual of the date command. You can forward the panels by pressing 
Enter. Enter quit to exit. 

man man Help for the manual. 

env Environment variables for this session. 
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type read Identifies, if read is a command, a utility, a alias, and so forth. 

type man 

type date 

Is List a directory. 

Is -1 List the current directory. 

Is -1 /etc List the directory /etc. 

cal Display a calender of the current month. 

cal 2004 Display a calender of 2004. 

cal 1752 Is September missing 13 days? All unix calendars have 13 days missing 
from September 1752. Optional - Do you know why? 

exit End the OMVS session. 


6.8.2 OEDIT and OBROWSE 


Another way to start the OMVS shell is by entering the TSO OMVS command the any ISPF 
panel. Make sure you are in your home directory. 


Enter the following shell commands 


oedit myfile This opens the ISPF edit panel and creates a new text file in the 
current path. Write some text into the editor. Save and Exit with PF3. 

Is 

Is -1 

type myfile Myfile is just a file. 

obrowse myfile Browse the file you just created. 

exit End the OMVS session. 
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6.9 Instructor notes 
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Refer to 6.1, “z/OS UNIX components” on page 6-1 

The POSIX standard introduced a new terminology in the z/OS environment. A typical 
UNIX operating system consists of a kernel which interfaces directly with the hardware. 
Built on the kernel is the shell and utilities layer that defines a command interface. Then 
there are application programs built on the shell and utilities. 


In a z/OS UNIX environment, the file system is considered part of the kernel because it is 
allocated to the kernel. The support for the file system is provided by the DFSMS 
product. Figure 6-13 shows the file system as part of the kernel and shows a logical view 
of the solution. 





Applications 





CC re ston BBX 
z/OS 
Shell and Utilities Compiler Debugger 





Language Environment 
for z/OS 


z/OS UNIX Kernel 


Process Management 
File Systems 
Communications 

Daemons REXxX Interface 
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Figure 6-13 The components of z/OS UNIX 


z/OS UNIX offers open interfaces for applications and interactive users on a z/OS 
system. The z/OS UNIX components and their functions are: 
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> The z/OS UNIX kernel 


At system initialization time, kernel services are started automatically. The kernel 
provides z/OS UNIX in response to requests from programs and from the shell. The 
kernel manages the file system, the communications, and the program processes. 


The hierarchical file system (HFS) is shipped as part of DFSMS. Other file systems 
can be used, such as NFS, zFS, and TFS. The FILESYSTYPE statement in the 
BPXPRMxx PARMLIB member is used to specify the file type. 


The z/OS UNIX API conforms to the POSIX and XPG4 standard. OS/390 was 
branded as a UNIX system by the Open Group in 1996. To support the APIs, the z/OS 
system must provide some system services which are included in the kernel, such as 
the file system and communication services. For more information about APIs, see 
“Additional information for z/OS UNIX APIs” on page 6-28. 


Daemons are programs that are typically started when the operating system is 
initialized and remain active to perform standard services. Some programs that 
initialize processes for users are considered daemons even though they are not 
long-running processes. z/OS UNIX supplies daemons that start applications and start 
a user shell session when requested. 


> The z/OS UNIX shell and utilities 
These are an interactive interface to z/OS UNIX that interprets commands from 
interactive users and programs. 
The shell and utilities component can be compared to the TSO function in z/OS. 


> The z/OS UNIX debugger (dbx) 


The z/OS UNIX debugger is a tool that application programmers can use to 
interactively debug a C program. The dbx debugger is not part of the POSIX 
standard. It is based on the dbx debugger that is well known in many UNIX 
environments. For more information about dbx, see “Additional information about 
the dbx debugger” on page 6-29. 





> The C/C++ compiler and C run-time libraries 











The C/C++ compiler and C run-time libraries are needed to make executables that the 
kernel understands and can manage. 


> Network File System (NFS) enables users to mount file systems from other systems 
so that the files appear to be locally mounted. You end up with a mixture of file 
systems that come from systems where the UIDs and GIDs may be independently 
managed. 


> Language Environment 


The C compiler and Language Environment feature are changed and extended to 
include support for the POSIX and XPG4 C function calls. The Language 
Environment product provides a common _ run-time environment and 
language-specific run-time services for compiled programs. 
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To run a shell command or utility, or any user-provided application program written 
in C or C++, you need the C/C++ runtime library provided with Language 
Environment. 


> The UNIX file system 


Any file from the z/OS UNIX file system is considered to be a “UNIX file.” On z/OS, 
the file system can be an HFS, TFS, or zFS (which is preferred). zFS is a high 
performance, log-based file system included in the Distributed File Service (DFS) 
base element of z/OS. zFS is a separate component of the DFS base element, so it can 
be serviced separately from the other components of DFS. 


The different application types can be developed in three different environments, 
depending on the preference of the application developer. A z/OS UNIX application is a 
C application that uses the XPG4.2-defined C calls to exploit z/OS UNIX. There is also 
support for mixed applications, which are applications that use z/OS UNIX as well as 
traditional MVS services. For example, an application can access both z/OS data sets and 
hierarchical files in the same program. However, environments that are not supported for 
use in z/OS UNIX C applications are: 


> CICS 
> IMS file system 


Traditional MVS applications are not affected by z/OS UNIX. 


Refer to 6.2.1, “z/OS UNIX interactive interfaces” on page 6-4 
The REXX support for z/OS UNIX is not really an interactive interface, but we chose to 
introduce it here since it is most often used in TSO or in the shell. The SYSCALL 
environment is not built into TSO/E, but an external function call called SYSCALLS will 
initialize the environment. Note that the shell is the initial host environment, which 
means that the SYSCALL environment is automatically initialized. A difference between 
the REXX support and shell scripts is that a REXX EXEC can be invoked from a C 
program, while a shell script can only be interpreted from the shell. A REXX EXEC can 
be called from a shell script. 
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Refer to 6.3, “Hierarchical file system (HFS)” on page 6-9 
Physical file systems 
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Figure 6-14 2/OS UNIX and physical file systems 


A PFS controls access to data. PFSs receive and act upon requests to read and write files 
that they control. The format of these requests is defined by the PFS interface. 


In a Z/OS UNIX environment, the physical file systems are defined in the BPXPRMxx 
PARMLIB member. ZFS, as a physical file system, is also defined in the PARMLIB 
member. Figure 6-14 shows all the physical file systems that can be defined in a z/OS 
UNIX environment. 


The PFS interface is a set of protocols and calling interfaces between the LFS and the 
PFSs that are installed on z/OS UNIX. PFSs mount and unmount file systems and 
perform other file operations. 


There are two types of PFSs, those that manage files and those that manage sockets: 


> File management PFSs, such as HFS and ZFS, deal with objects that have path names 
and that generally follow the semantics of POSIX files. 


> Socket PFSs deal with objects that are created by the socket() and accept() functions 
and that follow socket semantics. 
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ZFS file systems 
> ZFS isa "new" UNIX file system for z/OS . 


— Itis acomponent of the Distributed File Service since 1995. 
— It does not replace HFS. 


> Using ZFS, you can: 


— Run applications just like HFS. 
— Use ZFS in addition to HFS, or replace HFS. 


> Advantages: 


— Better performance 
— Enhanced administrative functions 
— Less loss of data on system failures 


ZFS focuses on local access. It can be locally mounted and is fully accessible from local 
z/OS UNIX applications. It is also available remotely via the z/OS DFS SMB server from 
Windows clients. 


ZFS does not replace HFS, rather it is complementary to HFS. HFS is required for z/OS 
installation and the root file system must be HFS. Like HFS, zFS is a UNIX file system. 
It contains files and directories that can be accessed with the APIs available for HFS. In 
general, the application view of zFS is the same as the application view of HFS. Once a 
ZFS file system is mounted, it is almost indistinguishable from any other mounted HFS. 
The benefits of using zFS are: 


> Improved performance 
> Underlying architecture to support additional functions 
> Improved crash recovery 


Studies indicate that there are many environments where zFS will perform better than 
HFS, and test runs show promising results. 
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HFS data sets 
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Figure 6-15 HFS data sets 


A z/OS UNIX hierarchical file system is contained in a data set type called HFS. HFS 
data sets can reside with other types of data sets on SMS-managed volumes or 
non-SMS-managed volumes. Multiple systems can share an HFS data set. 


An HFS data set is allocated by specifying HFS in the DSNTYPE parameter. You can 
also define a data class for HFS data sets. An HFS data set can be multivolume. A 
maximum of 59 physical volumes is supported. For the 3390-Model 3 DASD the 
maximum data set size would be 165.2 GB (59 * 2.8 GB). 


The z/OS UNIX file system is composed of multiple HFS data sets connected to each 
other in a hierarchy. On top of the hierarchy is the root file system, which contains system 
directories and files. Most installations will have user data in separate HFS data sets that 
are connected to the root. Connecting a file system to another is called mounting. 


Input, output, errors with the UNIX shell 


> Executing commands, REXX or C programs, the user has access to three files: 
— Input file - This is the input keyboard 
— Output file - Terminal screen by default 


Or, you can specify an HFS file 
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— Error file - Terminal screen for error messages 
Or, you can specify an HFS file 


> File names: 
— Input - stdin 
— Output - stdout 
— Error - stderr 


z/OS C/C++ programs require that stdin, stdout, and stderr be defined as either a file or a 
terminal. Many C functions use stdin, stdout, and stderr. However, it depends on how the 
application is coded whether or not it writes to stderr and stdout. 


When a shell command begins running, it has access to three files: 
> It reads from its standard input file. By default, standard input is the keyboard. 
> It writes to its standard output file. 


— Ifyou invoke a shell command from the shell, a C program, or a REXX program 
invoked from TSO READY, standard output is directed to your terminal screen by 
default. 


— Ifyou invoke a shell command, REXX program, or C program from the ISPF 
shell, standard output cannot be directed to your terminal screen. You can specify 
an HFS file or use the default, a temporary file. 


> It writes error messages to its standard error file. 


— Ifyou invoke a shell command from the shell or from a C program or from a 
REXX program invoked from TSO READY, standard errors are directed to your 
terminal screen by default. 


— Ifyou invoke a shell command, REXX program, or C program from the ISPF 
shell, standard errors cannot be directed to your terminal screen. You can specify 
an HFS file or use the default, a temporary file. If the standard output or standard 
error file contains any data when the command completes, the file is displayed for 
you to browse. 


Refer to 6.4, “z/OS UNIX programs (processes)” on page 6-12 
Create a process 


Fork() is a POSIX/XPG4 function that creates a duplicate process referred to as a child 
process. The process that issues the fork() is referred to as the parent process. 


With z/OS UNIX, a program that issues a fork() function creates a new address space that 
is a copy of the address space in which the program is running. The fork() function issues 
a program call to the kernel to create the child process. The contents of the parent address 
space are then copied to the child address space. 
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The child address space is almost an identical copy of the parent address space. User 
data, such as private subpools, and system data, such as recovery termination 
management (RTM) control blocks, are identical to those of the parent address space. 


After the fork() function completes, the program in the child address space starts at the 
same instruction as the program in the parent address space. Control is returned to both 
programs at the same point. The only difference that the program sees is the return code 
from the fork() function. A return code of zero is returned to the child after a successful 
fork(). The parent, however, receives the child’s PID (a unique identifier assigned to a 
process while it’s running) as the return value from fork(). 
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Figure 6-16 Creating a process 


A process can be created by using any of the following methods: 
> C fork() function 

Creates a child process that is identical to the parent process in a new address space. 
> Cspawn() function 


Creates a child process that will execute a different program than the parent. The 
child process is created in either a new address space or in the same address space as 
the parent process (local spawn). 
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> z/OS UNIX callable services 


When a program uses a z/OS UNIX assembler callable service, the z/OS address 
space is dubbed a z/OS UNIX process. The address space gets a PID. The dub does 
not result in a new address space. 


The kernel interfaces to z/OS Workload Manager (WLM) to create the new address space 
for a fork or spawn. WLM uses an IBM-supplied procedure named BPXAS to start up a 
new address space. This new address space then initializes the UNIX child process to run 
in the address space. After the child process completes, this address space can be reused 
for another fork or spawn. If none is waiting, BPXAS times out after being idle for 30 
minutes. 


2/OS UNIX processes 
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Figure 6-17 z/OS UNIX processes 


z/OS UNIX uses processes to run programs, and to associate resources to the programs. 
A z/OS address space can contain one or multiple processes. A process is created by 
another process, or by a request for z/OS UNIX. The process that creates a new process is 
called a parent process and the new process is called a child process. There will be a 
hierarchy of processes in the system. 


Every process is identified by a process id (PID) and is associated with its parent process 
by a parent process id (PPID). 
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z/OS UNIX supports processes that run in unique address spaces. These would be created 
by fork(Q) and exec() services. It also supports local processes. These will share an address 
space and are created by the spawn() service. 


The system also assigns a process group identifier (PGID) and a process identifier (PID). 
When only one command is entered, the PGID is the same as the PID. The PGID can be 
thought of as a system-wide identifier. If you enter more than one command at a time 
using a pipe, several processes, each with its own PID, will be started. However, these 
processes all have the same PGID and shell job identifier. The PGID is the same as the 
PID for the first process in the pipe. Process identifiers associated with a process are as 
follows: 


PID A process ID. A unique identifier assigned to a process while it runs. When 
the process ends, its PID is returned to the system. Each time you run a 
process, it has a different PID (it takes a long time for a PID to be reused by 
the system). You can use the PID to track the status of a process with the ps 
command or the jobs command, or to end a process with the kil] command. 


PGID Each process in a process group shares a process group ID (PGID), which is 
the same as the PID of the first process in the process group. This ID is used 
for signaling related processes. If a command starts just one process, its PID 
and PGID are the same. 


PPID A process that creates a new process is called a parent process; the new 
process is called a child process. The parent process ID (PPID) becomes 
associated with the new child process when it is created. The PPID is not used 
for job control. 


A process can create one or more child processes, and the child processes can be parent 
processes of new child processes, thus creating a hierarchy of related processes. The 
PPID maintains the relationship between processes. Usually, a process creates a child 
process to perform a separate task, for example a shell command. The child process ends 
when the task is completed while the parent process continues to execute. If for some 
reason a parent process should terminate before a child process, the child process 
becomes an orphan process. Orphan processes are inherited by the first process created in 
the system, called the init process. 
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Additional information for zZ/OS UNIX APIs 
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Figure 6-18 Means of interacting with the z/OS UNIX kernel 


A user can interact with z/OS UNIX through any of the following interfaces: 


> 
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Application Programming Interface (API) 


The API consists of C programming calls which can be used (by C/370 programs) to 
access z/OS UNIX. These C calls are defined in the POSIX 1003.1 standard. Many of 
the C calls use callable services to interact with the z/OS system to perform the 
services requested. Some C calls interface directly with the z/OS UNIX kernel. 


Assembler programs can use the callable services directly to access files in the file 
system. This capability allows Assembler programs and those coded in other 
high-level languages (excluding C) to use z/OS UNIX. 


The API interface provides the ability to run XPG4.2 programs on z/OS. A program 
that conforms to the XPG4.2 standard can be developed on one system and then 
ported to another system, compiled and link-edited, and executed on that system. 


A programmer can develop a program that uses a mix of standard z/OS services and 
z/OS UNIX. Such a program is often referred to as a mixed program. A mixed 
program can, for example, be a z/OS program that uses some of the Assembler 
callable services to access files in the hierarchical file system or to create a pipe for 
temporary data storage. 
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> The shell 


The interactive interface is called the z/OS UNIX shell. The shell is a command 
interpreter that accepts commands defined in the POSIX 1003.2 standard. Shell 
commands can be put together in a sequence, stored in a text file as a shell script, and 
executed. The shell script is similar to z/OS CLISTs and REXX execs. A REXX exec 
using z/OS UNIX can be run from TSO/E, in z/OS batch, or in the shell. 


For more information about the shell, see 6.2, “z/OS UNIX shell” on page 6-3. 


You can use a set of z/OS UNIX extensions to TSO/E REXX—host commands and 
functions—to access kernel callable services. The z/OS UNIX extensions, called syscall 
commands, have names that correspond to the names of the callable services that they 
invoke, for example access, chmod, and chown. 


You can run a REXX program with z/OS UNIX extensions from TSO/E, the shell, or a C 
program. The REXX exec is not portable to an operating system that does not have z/OS 
UNIX installed. 


The physical file system (PFS) interface is a set of protocols and calling interfaces 
between the logical file system (LFS) and the PFSs that are installed on z/OS UNIX. Ina 
z/OS UNIX environment, UNIX programs and UNIX users access their files through 
these interfaces. PFSs mount and unmount file systems and perform other file operations. 


Additional information about the dbx debugger 
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Figure 6-19 2/OS UNIX dbx debugger 
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The z/OS UNIX dbx debugger is an interactive tool for debugging C language programs 
that use z/OS UNIX. It is based upon the dbx debugger, which is regarded as an industry 
standard on UNIX systems. 


The dbx debugger provides the options to debug at source level or assembler level. 
Source-level debugging allows you to debug C language programs. Assembler-level 
debugging allows you to debug executable programs at machine code level. 


The dbx debugger is a utility that is invoked from the z/OS UNIX shell. It cannot be 
invoked directly from TSO/E. In the shell, dbx is the debugging facility for z/OS C/C++ 
programs. With dbx, you can debug multithreaded applications at the C-source level or at 
the machine level. Support for multithreaded applications gives you the ability to: 


> Debug or display information about the following objects related to multithreaded 
applications: threads, mutexes, and condition variables. 


> Control program execution by holding and releasing individual threads. 


With the interactive dbx debugger you can: 
> Runa program one line or one instruction at a time. 


> Set breakpoints at selected statements and machine instructions with conditions for 
activation. 


> Access variables symbolically and display them in the correct format. 

> Display or modify the contents of registers, variables, and storage. 

> Examine the source text using simple search functions. 

> Debug processes that contain fork() and exec() functions. 

> Interrupt and examine a program that is already in progress. 

> Trace processing of a one-task program by line, instruction, routine, or variable. 
> Call programs or diagnostic routines directly from the debug program. 

> Invoke shell commands from the debug session. 


> Examine loaded address maps for a process. 
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Communications overview 
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> 
> 
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Objective: In working with z/OS network communications, you will need to 
interact with TCP/IP and SNA networks. 


In this chapter, you will learn: 


How various communication network layered models compare with each 
other 

The software components of the z/OS Communications Server product 
How the SNA subarea and APPN network topology compare 

How the IP network can be used to transport data between SNA 
applications 

Commonly used TCP/IP and VTAM commands 
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7.1 Communications in Z/OS 


Communications has both software and hardware aspects, and a separation of software 
and hardware communications duties is common in large enterprises. A skilled software 
data communication expert, however, needs to understand both aspects. 


The z/OS system programmer must bring a thorough understanding of z/OS 
communications software to any project that involves working with the company’s 
network. While network hardware technicians have specific skills and tools for 
supporting the physical network, their expertise often does not extend to the z/OS 
communications software. When a nationwide retail chain opens a new store, the z/OS 
system programmers and network hardware technicians must coordinate their efforts to 
open the new store. 
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Figure 7-1 IBM communications server 
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z/OS includes a fully featured communications server with multiprotocol networking. 
This chapter begins with an overview of the available networking technologies on z/OS 
and then discusses the main operational aspects of the operating system’s 
communications server in 7.5, “z/OS Communications Server” on page 7-6. 


7.2 SNA and TCP/IP on z/OS 
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System Network Architecture (SNA) was developed by IBM. SNA provided industry 
with a technology that permitted unparalleled business opportunities. SNA included 
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products such as Virtual Telecommunication Access Method (VTAM), Network Control 
Program (NCP) and terminal controllers to expand the reach of the mainframe’s hosted 
data and processing capability using the synchronous data link control (SDLC) protocol. 
What TCP/IP and the Internet were to the public in the 1990s, SNA was to large 
enterprises in the 1980s. 


Transmission Control Protocol/Internet Protocol (TCP/IP) is an industry-standard, 
nonproprietary set of communications protocols that provide reliable end-to-end 
connections between applications over interconnected networks of different types. 
TCP/IP was widely embraced when the Internet came of age because it permitted access 
to remote data and processing for a relatively small cost. TCP/IP and the Internet resulted 
in a proliferation of small computers and communications equipment for chat, e-mail, 
conducting business, and downloading and uploading data. 


Large SNA enterprises have recognized the increased business potential of expanding the 
reach of SNA-hosted data and applications to this proliferation of small computers and 
communications equipment in the customers’ homes, small offices, and so on. 


7.3 Brief history of data networks 


Established in 1969, TCP/IP is actually five years older than SNA. Differences in the 
introduction of each technology stem mainly from the factors of commercial availability 
and technical maturity. SNA was immediately available to the public, while TCP/IP was 
limited at first to military and research institutions, for use in the interconnected networks 
that formed the precursors to the Internet. 


SNA was designed to include network management controls through Synchronous Data 
Link Control (SDLC) protocol. SNA also supported non-SDLC protocols, such as 
start-stop (SS) and bisynchronous (BSC) protocol. In the 1980s, SNA was widely 
implemented by large corporations because it allowed their IT organizations to extend 
central computing capability worldwide with reasonable response times and reliability. 
For example, widespread use of SNA allowed the retail industry to offer new company 
credit card accounts to customers at the point-of-sale. 


In 1983, TCP/IP entered the public domain in Berkeley BSD UNIX. TCP/IP maturity, 
applications and acceptance advanced through an open standards committee using the 
Request-For-Comment (RFC) mechanism. 


TCP/IP was designed for interconnected networks (an internet), while SNA design was 
hierarchical with the “centralized” mainframe being at the top of the hierarchy. The SNA 
design included network management, data flow control, and the ability to assign “class 
of service” priorities to specific data workloads. 
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Communication between autonomous SNA networks became available in 1983. The 
ability of independent SNA networks to share business application and network 
resources is called SNA Network Interconnect (SNI). 


7.4 Layered network models 
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TCP/IP and SNA are both layered network models. Each can indirectly map to the 
international Open Systems Interconnect (OSI) network model (Figure 7-2). 
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Figure 7-2. Open Systems Interconnect (OSI) network model 


The OSI network model depicts the organization of the individual elements of 
technology involved with end-to-end data communication. As shown in Figure 7-2, the 
OSI network model provides some common ground for both SNA and TCP/IP. While 
neither technology maps directly into the OSI network model (TCP/IP and SNA existed 
before the OSI network model was formalized), common ground still exists due to the 
defined model layers. 


The OSI network model is divided into seven layers. OSI layer 7 (Application) indirectly 
maps into the top layers of the SNA and TCP/IP stacks. OSI layer 1 (Physical) and layer 
2 (Data Link) map into the bottom layers of SNA and TCP/IP stacks. 


In one typical scenario, two geographically separated end-point software applications are 
connected at each end by a layered network model. Data is sent by one end-point 
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application and received by the other end-point application. The applications can reside 
on large mainframes, PCs, point-of-sale (POS) devices, ATMs, terminals, or printer 
controllers. 


Consider how this model might be used in the network communications between a large 
chain of grocery stores. Each time a customer pays for groceries at one of the many 
point-of-sale (POS) locations in a grocery store, the layered network model is used twice: 


> The POS application resides at the top of the local layered network stack. 


> The application that records details of the sale and authorizes completion resides at 
the top of a remote layer network stack. 


The local network stack might run on an AIX system with attached POS devices, while 
the remote network stack would quite often run on a mainframe, to handle transactions 
received from all of the store locations. Method of payment, purchases, store location, 
and time are recorded by mainframe applications, and authorization to print a sales 
receipt is returned back through both layered network stacks to complete the sale. 


This transactional model is commonly known as a request/server or client/server 
relationship. 


7.4.1 Network reliability, availability, and serviceability 


What if the network or attached mainframe for our example grocery store chain were to 
somehow become unavailable? Most POS systems in use today include the ability to 
accumulate transactions in an intelligent store POS controller or small store processor. 
When the outage is corrected, the accumulated transactions can then be sent in bulk to the 
mainframe. 


In the previous example, the recovery of transactions would be essential to preventing 
bookkeeping and inventory problems at the store and in the chain’s central office. The 
cumulative effect of unaddressed, inaccurate records could easily destroy a business. 
Therefore, reliability, availability and serviceability (RAS) are just as important in the 
design of a network as they are in the mainframe itself. 


7.4.2 Factors contributing to the continued use of SNA 


SNA is stable, trusted and relied upon for mission-critical business applications 
worldwide. A significant amount of the world’s corporate data is handled by 
z/OS-resident SNA applications!, A distinctive strength of SNA is that it is 
connection-oriented with many timers and control mechanisms to ensure reliable 
delivery of data. 


' SNA applications running on z/OS are also known as VTAM applications. 
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7.5 z/OS 


Mainframe IT organizations are often reluctant and sceptical about moving away from 
SNA, despite the allure of TCP/IP and Web-based commerce. This reluctance is often 
justified. Rewriting stable, well-tuned business applications to change from SNA 
program interfaces to TCP/IP sockets is costly, time consuming, and risks negatively 
impacting response time performance. 


Many businesses choose to use Web-enabling technologies to make the vast amount of 
centralized data available to the TCP/IP-based Web environment, while maintaining the 
SNA APIs. This “best of both worlds” approach ensures that SNA and VTAM will be 
around well into the forseeable future. 


Communications Server 


z/OS includes the Communications Server, which is an integrated set of software 
components that enable network communications for applications running on z/OS. 
Communications Server provides the data transportation corridor between the external 
network and the business applications running on z/OS. 


z/OS Communications Server provides a set of communications protocols that support 
peer-to-peer connectivity functions for both local and wide-area networks, including the 
most popular wide-area network, the Internet. z/OS Communications Server also 
provides performance enhancements that can benefit a variety of TCP/IP applications. 


Communications Server includes a number of sophisticated products and functions. The 
three major components are: 


> Transmission Control Protocol/Internet Protocol or TCP/IP 


> Virtual Telecommunication Access Method or VTAM, which provides the 
capabilities of the IBM System Network Architecture (SNA) in z/OS 


> Communications Storage Manager or CSM, which provides a shared I/O buffer area 
for both TCP/IP and VTAM data flow 


Communications Server, with its combination of TCP/IP and SNA functions, is 
implemented on a number of platforms besides z/OS, for example AIX, Microsoft 
Windows, and Linux. As a result, z/OS application programmers can exploit 
technological advancements in communications (information access, electronic 
commerce, and collaboration) across distinctly different operating systems. 


The CSM function allows authorized host applications to share data without having to 
physically move the data. 
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7.6 TCP/IP overview 


TCP/IP is a collection of protocols (rules) to get network data from one device to another. 
It was first included in the UNIX system offered by the University of California at 
Berkeley, and is now delivered with most UNIX systems. 
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Figure 7-3 TCP/IP introduction 


All systems, regardless of size, appear the same to all other systems in the network. 
TCP/IP can be used over Local Area Network (LAN) hardware using most common 
protocols, and over Wide Area Networks (WANS). 


In a TCP/IP network environment, a machine which is running TCP/IP is called a host. A 
TCP/IP network consists of one or more hosts linked together via various communication 
links. Any host can address all the other hosts directly to establish communication. The 
links between networks are invisible to an application communicating with a host in a 
different network. 


7.6.1 Interconnecting TCP/IP networks 


An internet is a collection of networks, interconnected through TCP/IP to provide 
communication services. 
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Figure 7-4 Interconnection TCP/IP networks 


To interconnect two networks, you need a device attached to both that can forward 
information from one network to the other. These devices are referred to as gateways, or 
routers. All hosts on all networks within an internet communicate with one another as if 
all other hosts were on the same network. This allows you to communicate with any of 
the other systems in an internet. 


Bridge A node that connects two LANs within one network. 
Gateway A node that connects two networks. 
Router A node that serves as an intermediate node forwarding data from one 


node to another in the network. 


The term internet is used as a generic term for a TCP/IP network and should not be 
confused with the Internet, which consists of the large international backbone networks 
connecting all TCP/IP hosts that have links to the Internet backbone and provides them 
with a huge selection of information. 
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7.6.2 Using commands to monitor TCP/IP 
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z/OS supports TCP/IP commands found in other operating systems, such as: 


NETSTAT 
PING 
TRACERTE 
NSLOOKUP 


You can enter these commands from an authorized TSO session from: 


> The TSO Ready prompt 
> The ISPF command shell 


> Any ISPF command line by prefixing the command with TSO. 


These commands can also be issued by batch programs. 


To enter the same commands from the z/OS UNIX shell prompt, you would prefix the 
commands with the letter “o”. For example, ONETSTAT, OPING, and so on. 


Example 7-1 shows the results you might see when entering the NETSTAT command 


from the TSO Ready prompt. 


Example 7-1 Sample NETSTAT output 


**** NETSTAT GATE output **** 
Known gateways: 


NetAddress FirstHop Link Pkt Sz Subnet Mask 
Defaultnet 10.1.2.1 ETH 1492. = <none> 
10.0.0.0 <direct>  ETH1 1492) -0.255.255.0 
10.1.2.3 <direct> ETH1 576 HOST 
127.0.0.1 <direct> LOOPBACK 576 HOST 


**** NETSTAT BYTE output **** 
MVS TCP/IP Real Time 
User Id B Out B In 
BPXOINIT 0000000000 0000000000 
FTPD1 0000000000 0000000000 
HTTPD1 0000000000 0000000000 
INETD4 0000000000 0000000000 
PORTMAP 0000000000 0000000000 
TCPIP 0001189778 0000030622 
TCPIP 0000000000 0000000000 
TCPIP 0000001466 0000000560 
TCPIP 0000000560 0000001466 


Network Monitor 
L Port Foreign Socket 


10007. 0.0.0.0..0 
00021 0.0.0.0..0 
00080 0.0.0.0..0 
01023 +0.0.0.0..0 
00111 0.0.0.0..0 
00023: 10.1.2.24..3080 
00023 =—(0.0.0.0..0 
01027. = 127.0.0.1..1028 
01028 = 127.0.0.1..1027 


Subnet Value 


Listen 
Listen 
Listen 
Listen 
Listen 
Establsh 
Listen 
Establsh 
Establsh 
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Here, the results include the status of all known TCP/IP gateways, the type of link, link 
packet size, etc., followed by a display of all TCP/IP resources listening for new socket 
connections or established socket connections with Byte In and Byte Out counts during 
the life of the socket connection. 


If problems are indicated in the display, the z/OS system programmer can use utilities 
such as NETSTAT, PING and TRACERTE to further investigate problems in a network. 


7.6.3 Using commands to manage TCP/IP 


You can use the DISPLAY TCPIP and VARY TCPIP commands to manage the network 
on z/OS. 


These commands include additional options, such as the following: 
> The DISPLAY TCPIP options include NETSTAT. 


> The VARY TCPIP command includes options to: 
— Drop specific socket connections 
— Start or stop communication devices 
— Display activity statistics 
— Display configuration information 
— Alter the TCP/IP network configuration 


For more information about the IP commands, refer to Communications Server Quick 
Reference; see “z/OS Communications Server Reference” on page H-1. 


7.7 VTAM overview 


7-10 


In z/OS, VTAM provides the SNA layer network communication stack to transport data 
between applications and the end user. VTAM manages the SNA-defined resources, 
establishes sessions between these resources, and tracks session activity. 


z/OS runs only one VTAM address space. Each application that uses VTAM, such as 
CICS/TS, requires a VTAM definition. The application and VTAM use this definition to 
establish connections to other applications or end users. 


Each end point of a VTAM application session is known as a logical unit (LU). Each LU 
is assigned a unique network addressable unit (NAU) to facilitate communication. An 
LU is a device or program by which an end user (application program, a terminal 
operator, or an input/output mechanism) gains access to the SNA _ network. 
VTAM-established sessions are known as LU-to-LU sessions. In an SNA network, 
CICS/TS, for example, is considered an LU and typically has many sessions with other 
LUs, such as displays, printers, POS devices, and other remote CICS/TS regions. 
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Figure 7-5 VTAM overview - the SNA environment 











A physical unit (PU) controls one or more LUs. A PU is not literally a physical device in 
the network. Rather, it is a portion of a device (usually programming or circuitry, or both) 
that performs control functions for the device in which it is located and, in some cases, 
for other devices that are attached to the PU-containing device. 


A PU exists in each node of an SNA network to manage and monitor the resources (such 
as attached links and adjacent link stations) of the node. 


The PU exists either within the device or within an attached controlling device. VTAM 
must activate the PU before it can activate and own each LU attached to the PU. 


Even the mainframe is a type of PU, with attached LUs of which CICS/TS is an example. 
There are three types of PUs: 


> PU Type 5S is in the mainframe. 

> PU Type 4 is a wide-area network communication controller. 

> PU Type 2 is a peripheral communication controller. These can be directly attached to 
the mainframe or to PU Type 4. 
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7.8 Network topologies supported by VTAM 


The hierarchical design of SNA serves the centralized data processing needs of large 
enterprises. At the top of this hierarchy is VTAM. 


VTAM serves the following types of network topologies: 


> Subarea 
>» Advanced Peer-to-Peer Network (APPN) 
> Subarea/APPN mixed 


The part of VTAM that manages a subarea topology is called System Services Control 
Point (SSCP). The part of VTAM that manages APPN topology is called Control Point 
(CP). 


VTAM subarea networks predate APPN. In many large enterprises, migration of subarea 
networks to an APPN topology is a desired technical objective. The migration allows the 
business to exploit APPN capabilities such as TCP/IP packet enveloping of SNA 
application data. Doing so permits elimination of older SNA-specific communication 
equipment by redirecting SNA data flows through existing TCP/IP communication 
networks. Also, WTAM _ administration and required coordination between 
communication hardware and software personnel can be significantly reduced with a 
pure APPN topology as a result of its increased flexibility over subarea networks. 


All three VTAM configuration types (subarea, APPN, and mixed subarea/APPN) exist 
throughout the world’s large enterprises. 


7.8.1 What a subarea network topology is 
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The distinguishing characteristics of a VTAM subarea network include the ownership 
and sharing of SNA resources. A subarea is a collection of SNA resources controlled by 
a single VTAM address space or a Network Control Program (NCP). 


A single VTAM and the SNA resources it owns is called a domain. A cross-domain 
resource manager, CDRM, allows for communication between VTAMs in the SNA 
network. When an LU requests a session to be established with an LU in a separate 
VTAM domain, the VTAMs cooperate to establish a cross-domain session. 


Figure 7-6 on page 7-13 shows a pure VTAM subarea network. This diagram might, for 
example, be representative of a business that is based in New York City with a large 
presence in Los Angeles, and a later expansion into Chicago. 


In Figure 7-6, the network communication between cities is made possible through the 
use of SNA wide-area communication controllers (3725s or 3745s), loaded with a 
network control program (NCP). The NCP provides data flow control between PUs and 
LUs located in three the cities. 
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NCP, like VTAM, is a subarea. NCP, however, does not start or own SNA resources. 
Rather, NCP is part of a VTAM domain. The first VTAM to activate NCP would own it 
and the NCP-attached PUs and LUs when no owner is explicitly coded on the PU or LU 
definitions. 


Figure 7-6 includes three VTAM domains and six subareas. The Chicago subarea could 
be controlled and managed by any of the three VITAM domains. The first VTAM to 
activate the Chicago NCP will own the PUs and LUs located in the Chicago subarea. 


In general, full migration from the older subarea topology to an APPN topology is a 
desired technical objective due to opportunities to leverage a newer IP network 
infrastructure and the cost reduction associated with elimination of older SNA network 
equipment. 
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Figure 7-6 A pure VIAM subarea network 
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7.8.2 What an APPN network topology is 
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Advanced Peer-to-Peer Networking (APPN) is a kind of data communications support 
that routes data in a network between two or more systems that do not need to be directly 
connected. 


APPN topology does not have a subarea number, nor does it have exclusive ownership of 
the SNA resources. Each APPN-participating VTAM is included in a geographically 
dispersed collection of shared SNA resources, eliminating the need for a cross-domain 
resource manager to establish sessions. 


APPN includes a high-performance routing (HPR) method of sending SNA application 
data through existing TCP/IP network equipment. APPN includes a function called 
Extended Enterprise (EE), sometimes referred to as HPR/IP. EE ensures that SNA 
applications can be served by state-of-the-art IP networking technology. 


Assume that the company shown in Figure 7-6 on page 7-13 later migrates from subarea 
network topology to APPN topology. Figure 7-7 on page 7-15 shows the same company 
after migration. 
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Figure 7-7 APPN topology 


7.8.3 Summary of VTAM topologies 


VTAM can be a subarea SSCP, an APPN CP, or both SSCP and CP serving a mixed 
network. The newer APPN topology is a desired architecture because of its ability to 
directly participate with existing IP infrastructures. 


The original subarea SSCP VTAMs will naturally evolve into a mixed subarea SSCP and 
APPN CP to take advantage of EE HPR/IP function and reduce costs of network-attached 
SNA communication equipment. This will most likely lead to subsequent decisions to 
migrate all remaining subareas to APPN topology to reduce network complexity. 
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7.8.4 Using commands to monitor VTAM 


The list below is a small sampling of VTAM commands used to gather information about 
a VTAM environment. 


> List the status of VTAM resources with DISPLAY(D NET,) commands, for example: 


D NET, VTAMOPTS Displays VTAM startup options. 

D NET, CSM[,OWNERID=ALL] Displays communication storage usage. 

D NET,APPLS Displays status of defined applications (ACBs). 

D NET,MAJNODES Displays status of VTAM activated ATCCONxx 
members. 

D NET, TOPO,LIST=SUMMARY Displays APPN topology information. 

D NET, CPCP Displays status of APPN CP-CP sessions. 

D NET, SESSIONS Displays status of subarea SSCP-SSCP sessions. 

D NET, CDRMS Displays status of subarea cross domain resource 
managers. 

D NET,EXIT Displays status of VTAM exit points. 


> Activate/Deactivate VTAM resources with VARY (V NET,) commands. 
> Alter the VTAM environment with the MODIFY (F VTAM,) commands. 
> NetView and NPDA can monitor and report on status of VTAM resources. 


For more information about VITAM commands, see Communications Server SNA 
Operations; see “z/OS Communications Server Reference” on page H-1. 


7.8.5 3270 data streams 
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What HTML is to a Web application and browser, the 3270 data stream is to an SNA 
application and device in an LU-LU session. 


Specialized commands are embedded in the data of display screen devices and printers. 
The 3270 data stream is data with these embedded instructions and data field descriptors. 
The 3270 data stream commands are created and read by SNA applications, Physical 
Unit (PU) controllers managing the displays, and printers as well as TN3270 emulators 
available in AIX and PC operating systems. 


One of the most noteable advantages of the 3270 data stream is that a full screen of data 
entries and corrections will only be sent to the receiving SNA application when the Enter 
key or PF key is pressed. 


The 3270 data stream includes column and row addresses of data fields, along with data 
descriptors such as color, protected screen areas, and unprotected screen areas. 


When an SNA application sends data to a display screen, it includes column/row location 
placement of individual data fields, descriptors of the data fields, and the screen position 
of the cursor. The 3270 data stream ability to permit completion of data entry before 
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sending to the SNA applications saves the CPU from unnecessary interruptions. 
Conversely, every key stroke of a VT100 vi session requires CPU attention. Something 
needs to understand and execute the CNTL-G key stroke. 


The SNA 3270 data stream was critical to the success of the SNA network ability to 
centrally manage many thousands of geographically dispersed display screens and 
printers. 


7.9 Summary 


Enterprise networks can be designed, customized, operated, and supported using 
combined features and functions of both SNA and TCP/IP network layers using 
Communications Server on z/OS, ALX, Windows, Linux, and Linux on zSeries. 


The VTAM component of z/OS Communications Server will be supported for the 
foreseeable future. A significant number of large enterprises use 3270 and SNA 
applications and have no need to rewrite the business application SNA APIs. As a result, 
VTAM will be supported and enhanced while integrating it with new technologies. 


Enterprises can—for selected SNA workloads—use Communications Server products to 
replace some of the old SNA infrastructure components, such as the IBM 3745/45 (NCP) 
communication controller hardware or other channel-attached SNA controllers. 
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7.10 Discussion questions 


> What components are common between the SNA and TCP/IP network layers? 
> Is the majority of the world’s corporate data served by z/OS SNA applications? 


> Does a business need to rewrite SNA business applications to Web-enable the 
application? 


> What is the difference between an SNA subarea network and APPN topology? 
> Why is APPN topology more desirable than a SNA subarea network? 
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What do HTML and a 3270 data stream have in common? 

What is common about an IP address and an SNA “network addressable unit” 
(NAU)? 

What is common about an SNA subarea and IP? 

What is common about an IP packet and the SNA Basic Transmission Unit (BTU)? 
What z/OS Communications Server resources are shared by TCP/IP and VTAM? 


What z/OS Communications Server component provides a shared I/O data buffer area 
to both TCP/IP and VTAM? 


7.11 Demonstrations and exercises 
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1, 
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From SDSF, enter the VTAM command /D TCPIP,, NETSTAT,HOME and from ISPF 
enter TSO NETSTAT HOME. 


— Is the output from each command the same? What is the home IP address or 
addresses of this z/OS system? 


From SDSF, enter the VTAM command /D NET,CSM. 


— How much space TOTAL ALL SOURCES is INUSE? 
— How much space TOTAL ALL SOURCES is FREE? 
— How much space TOTAL ALL SOURCES is AVAILABLE? 


From SDSF, enter the following VTAM commands: 


/D NET 

/D NET,APPLS 

/D NET,MAJNODES 

/D NET, TOPO,LIST=SUMMARY 

/D NET,CPCP 

/D NET,SESSIONS 

/D NET,SESSIONS, LIST=ALL 

/D NET, TSOUSER, ID=yourid 
Write down yourIPaddress ss 
Briefly describe how the output of this command could be useful. 
From ISPF start the z/OS UNIX shell with TSO OMVS. 


— Enter onetstat -h. 
Same information as in Exercise 1? 


— Note that you can use the TCP/IP commands from the z/OS UNIX shell as well 
(prefix 0). 


— Enterping your.ip.addr.ess. 


— Enter traceroute your.ip.addr.ess. 
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Maybe the traceroute command is called tracert. 


— Enter nslookup. 
¢ Entera WWW address, like www.ibm.com. 


Exit the nslookup (Nameserver Lookup) (exit). 
— Exit the z/OS UNIX shell (exit). 
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7.12 Instructor notes 
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Refer to 7.6, “TCP/IP overview” on page 7-7 

It is useful to know that TCP/IP originated in the US Department of Defense in the mid 
'70s and became the networking solution used in most UNIX systems in academic and 
research environments. Because of this, TCP/IP was not designed to fulfill performance 
and availability requirements for commercial businesses, but rather to provide the best 
connectivity between different systems. However, in recent years TCP/IP has become the 
networking choice for many commercial businesses and there has been work done to 
improve the weaknesses of TCP/IP (performance and reliability). 


The TCP/IP architecture consists of four layers, compared to the seven layers in SNA 
architecture. The layers between these architectures cannot be directly compared. They 
are: 


Application layer User programs or standard TCP/IP applications (FTP, TELNET, 
and so forth). 

Transport layer Contains the protocols providing end-to-end transfer between 
logical network addresses. Two protocols are provided: TCP 
and UDP. 


Internetwork layer Internet Protocol (IP) is the most important protocol here. It is 
responsible for routing data from a program on one system 
through the physical network to the receiving system. 


Network hardware interface 
Interface to the hardware network environment, for example 
LAN or X.25. 


TCP/IP got its name from two of the protocols in the layers. 


Refer to 7.6.1, “Interconnecting TCP/IP networks” on page 7-7 
Introduce the words bridge, gateway and router. They perform similar functions. A 
bridge always connects LANs within the same network. A gateway connects different 
networks, and routers are also gateways for their own networks, but act as an 
intermediate station in a data transfer process. The router receives data, determines the 
next gateway/router, and forwards the data to that gateway/router. 


TCP/IP is a peer-to-peer network. It is more similar to APPN than to a classical 
hierarchical SNA structure. A major difference between APPN and TCP/IP is that a 
TCP/IP gateway or router does not have information about the network topology as 
APPN nodes do. A TCP/IP node only knows the closest gateway to route data to. APPN 
nodes are able to collect information about path availability and can select the best path 
to send data over. 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter7 communications.fm 


TCP/IP networks are usually referred to as an internet (first letter is in lowercase). This 
should not be confused with the Internet (first letter is in uppercase), although the 
Internet is a collection of worldwide internets. 


Additional information about Internet addresses 


TCP/IP uses Internet addresses to interconnect different physical networks and have 
them appear as one large network to the application. 


> One or more TCP/IP hosts can be linked in a single network, for example, host A and 
host B. In another network, host B is connected with host C. 

> In Internet terms, host B is a gateway. For both networks, host B is seen as a normal 
host, but is capable of forwarding packets between hosts in different networks, and it 
has extra routing capabilities. 

> The IP address of a host identifies it uniquely to the network. IP addresses are written 
in dotted decimal form. The IP address is an address pair: 
— Network address - Identifies the network to which the host belongs, is assigned by 

a central authority, and is unique in the Internet. 

— Host address - Uniquely identifies the host within a network. 

> IP addresses can be split in different ways, depending on the class of the address. 


IPv6 is an evolutionary step from IPv4. IPv6 uses a 128-bit address space, which has no 
practical limit on global addressability and provides 340 billion billion billion billion 
unique addresses. 


z/OS Communications Server V1 R4 is the first release to incorporate IPv6 features. Not 
all IPv6 features are supported in this release. This release enables you to: 


> Build an IPv6 network 
> Start using IPv6-enabled applications 
> Enable existing IPv4 applications to be IPv6 applications 


Refer to “Using commands to manage TCP/IP” on page 7-10 
Sample output from the TCPIP DISPLAY command 


Security and integrity are critical in large corporate networks. The system operator can 
check for network intrusions by entering the DISPLAY TCPIP command with the IDS 
option, which invokes z/OS Intrusion Detection Services. 


The resulting output (Example 7-2) can help the operator determine whether a suspicious 
activity occurred in the network, such as receipt of an abnormal amount of malformed 
packets. 


Example 7-2 Intrusion Detection Services option 


D TCPIP, ,NETSTAT, IDS 
EZZ2500I NETSTAT CS V1R5 TCPIP 950 
INTRUSION DETECTION SERVICES SUMMARY: 
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SCAN DETECTION: 
GLOBRULENAME: *NONE* 
ICMPRULENAME: *NONE* 


TOTDETECTED: 0 DETCURRPLC: 0 
DETCURRINT: 0 INTERVAL: 0 
SRCIPSTRKD: 0 STRGLEV: 00000 


ATTACK DETECTION: 
MALFORMED PACKETS 
PLCRULENAME: *NONE* 
TOTDETECTED: 0 DETCURRPLC: 0 
DETCURRINT: 0 INTERVAL: 0 
OUTBOUND RAW RESTRICTIONS 
PLCRULENAME: *NONE* 
TOTDETECTED: 0 DETCURRPLC: 0 
DETCURRINT: 0 INTERVAL: 0 
RESTRICTED PROTOCOLS 
PLCRULENAME: *NONE* 
TOTDETECTED: 0 DETCURRPLC: 0 
DETCURRINT: 0 INTERVAL: 0 
RESTRICTED IP OPTIONS 
PLCRULENAME: *NONE* 
TOTDETECTED: 0 DETCURRPLC: 0 
DETCURRINT: 0 INTERVAL: 
ICMP REDIRECT RESTRICTIONS 
PLCRULENAME: *NONE* 
TOTDETECTED: 0 DETCURRPLC: 0 
DETCURRINT: 0 INTERVAL: 0 
IP FRAGMENT RESTRICTIONS 
PLCRULENAME: *NONE* 
TOTDETECTED: 0 DETCURRPLC: 0 
DETCURRINT: 0 INTERVAL: 0 
UDP PERPETUAL ECHO 
PLCRULENAME: *NONE* 


cS 


TOTDETECTED: 0 DETCURRPLC: 0 

DETCURRINT: 0 INTERVAL: 0 
FLOODS 

PLCRULENAME: *NONE* 

TOTDETECTED: 0 DETCURRPLC: 0 

DETCURRINT: 0 INTERVAL: 0 

TRAFFIC REGULATION: 

TCP 

CONNREJECTED: 0 PLCACTIVE: N 
UDP 

PCKDISCARDED: 0 PLCACTIVE: N 


INTRUSION DETECTION SERVICES TCP PORT LIST: 
INTRUSION DETECTION SERVICES UDP PORT LIST: 
0 OF O RECORDS DISPLAYED 
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7.13 Component identifiers (message prefix) 


Each IBM software component or product is assigned a 3-character identifier, which 
most commonly refers to a component identifier. It may also be called a product 
identifier. The first 3 characters of a message in the system log identify the component 
that produced the message. The following is a list of primary Communications Server 
software components with their respective 3-character message identifiers: 


Product 3-Character Identifiers 
TCP/IP EZA, EZB, EZY, EZZ 
VTAM IST 

CSM Monitor IVT 


TCP/IP has more than one component identifier. The TCP/IP component identifiers are 
divided into separate TCP/IP features and functions such as FTP, TELNET, etc. 


z/OS Communications Server - SNA includes VTAM. All messages in the system log 
prefixed by IST are VTAM (z/OS Communications Server-SNA) messages. 


z/OS Communications Server - IP includes TCP/IP. All messages in the system log 
prefixed by EZA, EZB, EZY and EZZ are TCP/IP (z/OS Communications Server-IP) 
messages. 


Communication Storage Manager (CSM) Monitor is used by VTAM and TCP/IP for its 
data I/O buffers; however, it is considered z/OS Communications Server-SNA because 
VTAM creates the space. 


7.14 More information about TCP/IP operation and 
configuration 


z/OS system programmers must know how to start, stop and modify TCP/IP, and 
periodically monitor its status. 

In the sections that follow, we examine: 

> A sample JCL procedure used to start TCP/IP on z/OS 

> Control statements to modify the behavior of TCP/IP 


> System commands used to monitor the functioning of TCP/IP 
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7.14.1 Starting TCP/IP on z/OS 


To start TCP/IP on z/OS, we could use a JCL procedure like the one shown in 
Example 7-3. 


Example 7-3. Sample procedure to start TCP/IP on z/OS 
{7 TCPIP PROC 


[ORR IIE IOI II IIR IIR IIR IIR IIR II ICI 

//* STARTING TCPIP 

//* Z/OS COMMUNICATIONS SERVER - IP 

[ORI IORI II IIR IIR IIR IIR III IIR IOI 
//TCPIP EXEC PGM=EZBTCPIP 

//PROFILE DD DISP=SHR,DSN=TCPIP.PARMS (PROFILE) 
//SYSTCPD DD DISP=SHR,DSN=TCPIP.PARMS (DATA) 


To ensure that TCP/IP is started when z/OS initializes, the system operator would enter 
START TCPIP to run this JCL during IPL. Similarly, the operator can stop TCP/IP while 
the system is active. All TCP/IP network connections are lost when TCP/IP is stopped. 


7.14.2 Defining TCP/IP through control statements 
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In Example 7-3, the data sets referenced by the JCL PROFILE DD statement and 
SYSTCPD DD statement contain definitions for creating a simple TCP/IP network. The 
content of these data sets is read by program EZBTCPIP. 


Example 7-4 and Example 7-5 on page 7-25 show the specific control statements that 
were used to define TCP/IP on the system. 


Example 7-4 Content of //PROFILE DD DSN=TCPIP PARMS(PROFILE) 
ARPAGE 5 


TELNETPARMS 
PORT 23 
ENDTELNETPARMS 
AUTOLOG 5 
FTPD JOBNAME FTPD1 ; FTP Server 
PORTMAP ; Portmap Server 
ENDAUTOLOG 
PORT 
20 TCP OMVS NOAUTOLOG ; FTP Server 
21 TCP OMVS 3; FTP Server 
23 TCP INTCLIEN ; Telnet Server 
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DEVICE Lesi. Les E20 
LINK ETH1 ETHERNET 1 LCS1 


HOME 
IQ. L233 ETH1 
GATEWAY 
: First Link Packet Subnet Subnet 
; Network Hop Name Size Mask Value 
10 = ETH1 1492 0.255.255.0 0.1.2.0 
DEFAULTNET 10.1.2.1 ETH1 1492 0 
BEGINVTAM 
DEFAULTLUS 
SCOTCPO1 SCOTCPO2 SCOTCPO3 SCOTCP04 SCOTCP05 
SCOTCP06 SCOTCPO7 SCOTCPO8 SCOTCP09 SCOTCP10 
ENDDEFAULTLUS 
USSTCP USSN ; USS Table name 
ENDVTAM 
3; Start all the defined devices. 
START LCS1 


In these examples, the control statements define: 


The home IP address 

The gateway IP address 

The router (DEFAULTNET) 

The communication adapter (DEVICE/LINK) 
The hostname 

The nameserver (NSINTERADDR) IP address. 


vvvvvy 


The statements also cause the FTP daemon and PORTMAP to be started automatically. 


Example 7-5 Contents of //SYSTCPD DD DSN=TCPIPPARMS(DATA) 


TCPIPJOBNAME TCPIP 
HOSTNAME zztop 
DOMAINORIGIN ibm.com 
NSINTERADDR 10.1.2.2 
NSPORTADDR 53 


The TCP/IP configuration defined here (Example 7-4 on page 7-24 and Example 7-5) 
would be a very simple network on z/OS. The actual configurations for large networks 
contain significantly more and varied network definitions. 
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7.14.3 Viewing TCP/IP initialization messages 


When you start TCP/IP on z/OS, it begins writing messages to the system log (or 
SYSLOG). These messages report problems that might have occurred during 
initialization, if any, and whether TCP/IP successfully initialized. 


Example 7-6 shows TCP/IP messages typically written to SYSLOG. 


Example 7-6 SYSLOG messages during TCP/IP initialization 


ITEF695I START TCPIP WITH JOBNAME TCPIP 

$HASP373 TCPIP STARTED 

EZZ0300I OPENED PROFILE FILE DD:PROFILE 

EZZ0309I PROFILE PROCESSING BEGINNING FOR DD:PROFILE 

EZZ0316I PROFILE PROCESSING COMPLETE FOR FILE DD:PROFILE 
EZZ0334I IP FORWARDING IS DISABLED 

EZZ0335I ICMP WILL NOT IGNORE REDIRECTS 

EZZ0338I TCP PORTS 1 THRU 1023 ARE RESERVED 

EZZ0338I UDP PORTS 1 THRU 1023 ARE RESERVED 

EZZ42021 OPENEDITION-TCP/IP CONNECTION ESTABLISHED FOR TCPIP 
EZZ43141 INITIALIZATION COMPLETE FOR DEVICE LCS1, LINK ETH1 
EZB64731 TCP/IP STACK FUNCTIONS INITIALIZATION COMPLETE. 
EZAIN11I ALL TCPIP SERVICES FOR PROC TCPIP ARE AVAILABLE. 
EZZ04001 TELNET/VTAM (SECOND PASS) BEGINNING FOR FILE: DD:PROFILE 
EZZ60031I TELNET LISTENING ON PORT 2a 

EZZ04031 TELNET/VTAM (SECOND PASS) COMPLETE FOR FILE: DD:PROFILE 


In Example 7-6, note the following: 
> Message EZZ4314] indicates that the communication adapter is ready. 


> Message EZB6473I indicates that the TCP/IP stack (Figure 7-2 on page 7-4) is 
loaded and ready for work. 


7.14.4 Dependencies 
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Two subsystem interfaces (TNF and VMCF) must initialize before all the z/OS 
Communications Server-IP components can initialize. Example 7-7 shows an extract of 
selected messages from the z/OS system log that are written soon after z/OS initial 
program load, or IPL. 


Example 7-7 Messages from the z/OS system log after IPL 


ITEEO42I SYSTEM LOG DATA SET INITIALIZED 
$HASP492 JES2 COLD START HAS COMPLETED 

EZY6018I TNF Initialization Complete 

EZY6011I VMCF Initialization Complete 

ISTO2Z0I VTAM INITIALIZATION COMPLETE FOR CSV1R5 
*EZZ9314E TCP/IP WAITING FOR OMVS TO INITIALIZE 
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BPXF203I DOMAIN AF_INET WAS SUCCESSFULLY ACTIVATED. 

BPXF2031I DOMAIN AF_UNIX WAS SUCCESSFULLY ACTIVATED. 

EZZ42021 OPENEDITION-TCP/IP CONNECTION ESTABLISHED FOR TCPIP 
EZB64731 TCP/IP STACK FUNCTIONS INITIALIZATION COMPLETE. 
EZAIN11I ALL TCPIP SERVICES FOR PROC TCPIP ARE AVAILABLE. 
BPXIOO4I OMVS INITIALIZATION COMPLETE 


Messages ending with “TI” are informational. Message EZZ9314E is TCP/IP reporting an 
error condition. TCP/IP is started on this system before Unix System Services is able to 
mount the file systems. TCP/IP does not fail, it is “waiting”. After the file systems are 
mounted, both TCP/IP and Unix System Services (OMVS) initialize. 


The system command D A,ALL will display the status of JES, TNF, VMCF, VTAM, 
OMVS, and TCP/IP components among all address spaces that were started. 


7.15 More information about VTAM operations and 
configuration 


7.15.1 Starting VTAM on z/OS 


To start VTAM on z/OS, we could use a JCL procedure like the one shown in 
Example 7-8. 


Example 7-8 Sample procedure to start VIAM on z/OS 
//VTAM — PROC 
[| [ RRRRRRRRRRRRRRRER ERE EER ERE ERE EERE RERE 


//* STARTING VTAM 
//* Z/OS COMMUNICATIONS SERVER - SNA 


[| [RRRRRRRRRRRRRRRERERERER ERE RR ER ERE RERE 


//NTAM EXEC PGM=ISTINMO1 
//NTAMLST DD DISP=SHR,DSN=SYS1.VTAMLST 
//VTAMLIB DD DISP=SHR,DSN=SYS1.VTAMLIB 


To ensure that VTAM is started when z/OS initializes, the system operator would enter 
START VTAM to run this JCL during IPL. Similarly, the operator can stop VTAM while 
the system is active. All SNA network connections are lost when VTAM is stopped. 


7.15.2 Defining VTAM with control statements 


In Example 7-8 on page 7-27, the data sets referenced by the JCL VIAMLST DD 
statement and the VITAMLIB DD statement contain network definitions and executable 
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modules with network customization. The content of these data sets is read by program 
ISTINMO1. 


VTAMLST member ATCSTRxx contains the VTAM startup parameters, which define 
the VTAM configuration, such as whether the VTAM is participating in a subarea 
topology and the APPN topology. To display the VTAM startup parameter values, enter 
the VTAM command D NET, VTAMOPTS. 


VTAMLST member ATCCONxx contains the names of the other VTAMLST data set 
configuration members, which are activated during VTAM startup. Each VTAMLST data 
set configuration member specified in ATCCONxx contains detailed definitions of 
various SNA resources available to the network, such as application control blocks 
(ACBs) for the VTAM applications and the network-attached communication equipment. 


During VTAM initialization, each member specified in ATCCONxx is automatically 
started. The statements in each member define resources being made available by this 
VTAM. See the VTAM Initialization system log in Example 7-9 on page 7-28. 


VTAMLIB members include local customization applied to the WTAM-controlled 
resources during startup. One of the compiled and linked modules in VTAMLIB is the 
initial 3270 signon screen sent to each 3270 display LU. This module is the unformatted 
session services (USS) module. It is simple assembler source code with 3270 data stream 
instructions. One way for students to become more familiar with VTAM and 3270 data 
streams is for them to modify the text of the USS 3270 signon screen (any such changes 
will need to be compiled and link-edited). 


7.15.3 Viewing VTAM initialization messages 
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When you start VTAM on z/OS (with command S VTAM), it begins writing messages to 
SYSLOG.. These messages report problems that might have occurred during 
initialization, if any, and whether VTAM successfully initialized. 


System command S VTAM will execute the JCL PROC VTAM. Example 7-9 shows the 
messages written to SYSLOG. 


Example 7-9 SYSLOG messages during VTAM initialization 


S VTAM 

$HASP373 VTAM STARTED 
ISTO931 ISTCDRDY ACTIVE 
ISTO931 COSAPPN ACTIVE 
ISTO931 ISTRTPMN ACTIVE 
ISTO931 ISTTRL ACTIVE 
ISTO931 CICAPPL ACTIVE 
ISTO931 TSOAPPL ACTIVE 
ISTO93I IMSAPPL ACTIVE 
ISTO93I JESNODE ACTIVE 
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ISTO931 XCANODE ACTIVE 

ISTO931 MCPNODE ACTIVE 

ISTO931 TCPXTSO ACTIVE 

ISTO201 VTAM INITIALIZATION COMPLETE FOR CSV1R5 
IST13491 COMPONENT ID IS 5695-11701-150 
IST1348I VTAM STARTED AS INTERCHANGE NODE 


7.16 SDLC protocol 


SNA data needs to be enveloped with information such as destination and return address. 
SDLC is the data envelope with all the required details to maintain an on-going LU to LU 
conversation such as CICS/TS would have with a display screen. Synchronous Data Link 
Control (SDLC) is a protocol for managing synchronous information transfer over a data 
link connection. 


This section describes the elements of SDLC without attempting to describe the SDLC 
flow protocols and rules. 


SDLC flow is very stable and provides excellent messaging and reason codes to provide 
explanations why a problem occurred, along with corrective action. As a result, it is 
increasingly rare for enterprises to need high SDLC flow skill levels. 


This section is intended to provide details behind the complexity of transporting business 
data in a network without any intention for you to memorize technical descriptions and 
functions of the SDLC envelope. 


SDLC is a bit-oriented protocol. Bit settings found in the SDLC headers and SDLC 
commands are interpreted and acted upon by the SNA network layers. Describing the 
individual SDLC header bit settings is also beyond the scope of this text. The following 
is the anatomy of an SDLC envelope flowing in an SNA environment. 


An example of SDLC used in an SNA LU to LU session can be explained using 
Figure 7-8 on page 7-30. When a display (LU) is in session with CICS/TS, the SNA 
network layer is used to send and receive application “user data”. The Function 
Management layer of the SNA network model indirectly maps to OSI model 
presentation, session and transport layers 6, 5 and 4, respectively. 


Data from the Display begins a trip through the SNA network layer with the <enter> key. 
This data must be enveloped, addressed and sent. The receiving end must remove the 
envelope, read the data, then send response data back to the sender (which requires a new 
envelope). 
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| OSI Model _| ISNA Network Layers 
Layer (7) [Application(LU) _| 

Layer (4. 5, 6) BIU 
Layer (3) PIU 
Layer (2) BLU 
Layer(1) _[<<<< Basic Transmission Unit >>>> [__Physical Control _|<<<< Basic Transmission Unit >>>> [Block BTU] 








Figure 7-8 SDLC example - send data to CICS/TS 


Using Figure 7-8, we will start at the Display and send data to CICS/TS. The display data 
(a 3270 data stream in this case) envelope is built, then placed on the Physical Control 
communication media for transport. 


The envelope building blocks include a Request or Response Unit (RU) to hold the user 
data, then a Request or Response Header (RH) is appended to the front of the user data by 
the Function Management layer of the SNA stack. The RH-RU is called a Basic 
Information Unit (BIU). A transmission header (TH) is appended to the front of the BIU. 
The TH-RH-RU is called a Path Information Unit (PIU). Data Link Control (DLC) bits 
are appended to both ends of the PIU. A PIU with DLC header and trailer is called a 
Basic Link Unit (BLU). 


Most commonly, the SNA DLC layer envelopes a multiple blocking of TH-RH-RU PIUs 
with a single header DLC and single trailer DLC bits before placing the frame on the 
physical layer for transmission. The Basic Transmission Unit (BTU) can be a single PIU 
or block of PIUs. The BTU with single header and trailer DLC bits is a Basic Link Unit 
(BLU). 


If you were able to follow the above description first time through, you have a strong 
affinity for data communications or prior working knowledge of TCP/IP data envelopes 
flowing in a TCP/IP network. 


When the BLU is received by the SNA network layer containing the CICS/TS 
application, the individual layers begin to read, react, and remove the SDLC fields on 
their way up the stack to be read by CICS/TS. The same process occurs when CICS/TS 
generates and returns a 3270 data stream response back to the display. 


The SDLC fields contain information such as: 


> Origin and target “network addressable units” 

> Whether the user data is at the beginning, middle, or end of the data chain 

> Whether or not the sender expects a positive response from the receiver confirming 
receipt of data 

> Whether the BTU bit count sent was the exact BTU bit count received. 
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7.17 More information about communication DLC 
device driver options 


Communications Server integration of SNA and IP networking stacks use common Data 
Link Control (DLC) routines to access network hardware, and both types of protocols 
can flow over the same hardware link. Also, common service routines such as 
Communications Storage Manager (CSM) exploit use of buffers in common storage for 
both IP and SNA performance. 


This design permits a wide variety of zSeries communication device driver options for 
external and internal network connections (between LPARs). The options can be 
classified into two categories: TCP-exclusive DLCs, and shared DLCs. TCP-exclusive 
DLCs are only available for z/OS IP stacks and cannot be shared between multiple 
instances of z/OS IP. Shared DLCs can be simultaneously used by multiple instances of 
multiple protocol stacks. 


The z/OS Communications Server-provided device drivers are base elements for a large 
enterprise data network communications architect. The zSeries hardware loaded with 
these device drivers would include ESCON channel, Open Systems Adapter (OSA), and 
internal components used for communications between LPARs. 


7.17.1 DLC device driver options 


The system programmer codes the Communications Server definition to load the selected 
Communications Server device driver and activate the network connections. 


Below is a list of device drivers that the network architect would choose from when 
designing or redesigning a network. Describing each device driver is beyond the scope of 
this chapter. The list is just here to show that a variety of network design options are 
available for connecting to external communications equipment and internal hardware 
components facilitating connections between LPARs. 


TCP-exclusive DLC adapter options include: 


Channel Data Link Control (CDLC) 

Common Link Access to Workstation (CLAW) 
Channel-to-Channel (CTC) 

Hyperchannel 

LAN Channel Station (LCS) 


vvvvy 


Shared DLCs include: 


> Multipath Channel+ (MPC+) 
> Port Adapter (CPA) 
> MPCIPA (QDIO) 
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> XCF 
> PTP Samehost 
> Hipersockets 





z/OS Communications Server (CS) Description 
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Figure 7-9 The z/OS Communications Server 
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Part 2 


Applications and development 
on z/OS 


In this part, we introduce the tools and utilities for developing a simple program to run on 
z/OS. 
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8 


Designing and developing 
applications for z/OS 








Objective: As your. company’s newest z/OS application 
designer/programmer, you will be asked to design and write new programs or 
modify existing programs to meet the company’s business goals. Such an 
undertaking will require that you fully understand the various user 
requirements for your application and know which z/OS system services to 
exploit. 


In this chapter, you will learn: 


> Who are application designers? Who are application programmers? 
Which tools are available to aid in the development of z/OS applications? 
What are the factors that can influence the design of a z/OS application? 
What types of decisions must a designer make? 








vvyv 
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8.1 Application designers and programmers 


The tasks of designing an application and developing one are distinct enough to treat 
each in a separate textbook. At larger z/OS installations, separate departments might be 
needed to carry out each task. 


This chapter provides an overview of these job roles and then shows how each skill fits 
into the overall view of a typical application development lifecycle on z/OS. 


The role of the application designer is not a trivial one. Determining the best solution for 
an important business requirement usually requires a fair amount of knowledge regarding 
the business itself, other roles in the mainframe organization such as programming and 
database design, and a general knowledge of the business’s hardware and software. The 
designer must have a global view of the entire project. Depending on the complexity of 
the project, the designer might involve other specialists to assist in the design process. 


Application programmers develop and maintain application programs. The application 
programmer builds, tests, and delivers the application programs that run on the 
mainframe and provides the business applications for the end users. The programmer 
takes requirements from business analysts and end users and constructs the application 
programs using a variety of tools. That build process includes many iterations of code 
changes and compiles, application builds, and unit testing. 


During this application development process, the programmer must interact with other 
roles in the enterprise. In addition to the input gathered from the user community, the 
programmer often works on a team of other programmers who are building code for 
related application modules. When the application modules are completed, they are 
passed through a testing process that can include functional, integration, and system tests. 
Following this testing process, the application programs must be acceptance-tested by the 
user community to determine whether the code actually accomplishes what the users 
desire. 


8.2 Application development lifecycle: An overview 
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As with other operating systems, application development on z/OS is usually composed 
of the following phases: 


> Design phase 
— Gather requirements. 
¢ User, hardware and software requirements 
— Perform analysis. 
— Perform design. 
¢ High-level design 
* Detailed design 
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— Hand over to application programmers. 
> Code and test application. 
> Perform user tests. 
— User tests application for functionality and usability 
> Perform system tests. 
— Perform integration test (test application with other programs to verify that all 
programs continue to function as expected). 
— Perform performance (volume) test using production data. 
> Go production—hand off to operations. 
— Ensure that all documentation is in place (user training, operation procedures). 
> Maintenance phase—ongoing day-to-day changes and enhancements to application. 


Figure 8-1 shows the process flow during the various phases of the application 
development lifecycle. 












Gather 
requirements 










Analysis 





Go - 
prodteron Maintenance 


Figure 8-2 depicts the design phase up to the point of starting development. Once all of 
the requirements have been gathered, analyzed, verified, and a design has been produced, 
we are ready to pass on the programming requirements to the application programmers. 


Code & test CS se 
tests 


Figure 8-1 Application development lifecycle 
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Figure 8-2 Design phase 


The programmers take the design documents (programming requirements) and then 
proceed with the iterative process of coding, testing, revising, and testing again, as we 


see in Figure 8-3. 
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Figure 8-3 Development phase 
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Once the programs have been tested by the programmers, they will be part of a series of 
formal user and system tests. These are used to verify usability and functionality from a 
user point of view, as well as to verify the functions of the application within a larger 


framework. See Figure 8-4. 
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Figure 8-4 Testing 


The final phase in the development lifecycle is to go to production and become steady 
state. As a prerequisite to going to production, the development team needs to provide 
documentation. This usually consists of user training and operational procedures. The 
user training familiarizes the users with the new application. The operational procedures 
documentation enables Operations to take over responsibility for running the application 
on an ongoing basis. Once in production, the changes and enhancements are handled by a 
group that performs this maintenance. This could also be the same group as the 
programmers. At this point in the lifecycle of the application, changes are tightly 
controlled and must be rigorously tested before being implemented into production. See 
Figure 8-5. 
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Figure 8-5 Production 


An application is a piece of software that satisfies certain specific requirements (resolves 
certain problems). The solution could reside on any platform or combination of 
platforms, from a hardware or operating system point of view. 


If we look at Figure 8-6 on page 8-6, we see that our specific application can be located 
in any of the three environments: Internet, enterprise network, or central site, and that the 
system should be in a position to provide access to any of these environments. 
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To begin the design process, we must first assess what we need to accomplish. Based on 
the constraints of the project, we must determine how and with what we will accomplish 
the goals of the project. To determine what needs to be accomplished, we must conduct 
interviews with the users (the ones requesting that we come up with a solution to a 
problem) as well as the other stakeholders. The results of these interviews feed into every 
subsequent stage of the lifecycle of the application project. At many stages of the project, 
we again call upon the users to verify that we have understood their requirements and 
that our solution meets their requirements. At these milestones of the project, we also ask 
the users to sign off on what we have done, so that we can proceed on to the next step of 











the project. 
Internet Enterprise Network Central Site 

1 Browser 
Web Appl. 
\ Server Server 

e-business # i 3 a G& 

Browser i 

Browser usiness Systems 
1 Web Appl. Databases 
i Server = Server 









e-business 
with Legacy Systems 
y J 
Personal 
Computer 
= 


Browser 
Applications 


Client-Server 


GUI Front End ; 
Business Systems 


Personal Computer Front End 


Terminal 
Processing 





1 
i 
i Business Systems 
1 
1 


Z 


"Dumb" Terminal 








Figure 8-6 Growing infrastructure complexity 


8.2.1 Gathering requirements for the design 


8-6 


When designing applications, there are many ways to classify the requirements: 
Functional requirements, non-functional requirements, emerging requirements, system 
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requirements, process requirements, constraints on the development and in the 
operation—to name a few. 


Computer applications operate on data, which resides somewhere and which needs to be 
accessed from either a local or remote location. The applications manipulate the data, 
performing some kind of processing on it, and then present the results to whomever was 
asking for in the first place. 


This simple description involves many processes and many operations that have many 
different requirements, from computers to software products. 


Although each application design is a separate case and can have many unique 
requirements, some of these are common to all applications that are part of the same 
system. Not only because they are part of the same set of applications that comprise a 
given information system, but also because they are part of the same installation, which 
is connected to the same external systems. 


One of the problems faced by systems as a whole is that components are spread across 
different machines, different platforms, and so forth, each one performing its work in a 
server farm environment. 


An important advantage to the zSeries approach is that applications can be maintained 
using tools that reside on the mainframe. Some of these mainframe tools make it possible 
to have different platforms sharing resources and data in a coordinated and secure way 
according to workload or priority. 


The following is a list of the various types of requirements for an application. The list is 
not exclusive; some items already include others. 


Accessibility 

Availability 

Backup ability 

Changeability 

Client 

Connectivity 

Distributed 

Inter-communicable 

Interoperability 

Performance 

Portability 

Preventing failure and fault analysis 
Recoverability 

Resource can be monitored, controlled, managed, and administered 
Secure centralized controllable capacity 
Server 

Serviceability 


vvvvvvvvvvvvrvvvviy 
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> Usability 
> Web services 


8.2.2 Decisions to be made based on user requirements 
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During the early design phases, the application designer makes many decisions regarding 
the final characteristics of the application. These decisions are based on many criteria, 
which must be gathered and examined in detail in order to arrive at a solution that is 
acceptable to the user. The decisions are not independent of each other, in that one 
decision will have an impact on others and all decisions must be made taking into 
account the scope of the project and its constraints. Keep in mind that the best systems 
are those that start with the end result in mind. We must know what it is that we are 


striving for before we start to design. 


Table 8-1 gives some examples of the decisions that the application designer might have 
to make during the design process for a given application. The list is not meant to be 


exhaustive, but rather to give you an idea of the process involved. 


Table 8-1 Design decisions and factors influencing those decisions 


Decisions 


Batch versus online 


Data file 
organization 


Computer language 
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Factors influencing decisions, and options 


What is the application attempting to do? 

What are the users’ access requirements to the data? 

What are the response time requirements for the application? 
Where does the data reside (tape versus online)? 


What must be stored? 

How will the data be accessed? 

Are the requests ad hoc or predictable? 

Batch or online? 

Will we choose PDS, DBMS, VSAM, or DB2? 


What type of application? 

Batch versus online? 

What are the response time requirements? 

What type of platform? 

What are the budget constraints for development, for ongoing 
support? 

What are the time constraints of the project? 

Do we need to write some of the subroutines in different languages 
because of the strengths of a particular language versus the overall 
language of choice? 

Do we use a compiled or an interpreted language? 

See Appendix 9, “Using programming languages on z/OS”, for a 
more detailed explanation of the differences between the various 
computer languages. 
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Decisions Factors influencing decisions, and options 


Software Do we use z/OS, UNIX, LINUX, or Windows as the operating 
system? 
Will a software package satisfy the users’ requirements or must a 
solution be developed? 
Could a software package satisfy some of the requirements? 


Hardware What is the quantity of data to store and access? 
Is there a need to share the data? 
What are the response time requirements? 
Do we use a small, medium, or large server? 
What are the cost constraints of the project? 
How many users will access the application at once? 
What is the availability requirement of the application (24 
hours/day, 7 days per week, 8:00 - 5:00, etc.)? 


Exception handling | Are there any unusual conditions that might occur? If so, then we 
need to incorporate these in our design in order to prevent failures 
in the final application. We cannot always assume that everything 
will be entered as expected. 





We have selected a list of products that support the z/Architecture, specifically, the z/OS 
operating system. Some of these products are priced offerings, some are part of the base 
(included in a component of the z/OS operating system), and others are optional. We are 
not differentiating between these types, because products are selected for technical 
reasons as well as for requirement reasons. This list is not complete and should not be 
used to configure a system. It is just for purposes of discussion against our list of possible 
requirements. 


8.3 Application development on z/OS 


After the analysis has been completed and the decisions have been made, the process 
passes on to the application programmer. The programmer is not given free rein, but 
rather must adhere to the specifications of the designer. However, given that the designer 
is probably not a programmer, there may be changes required because of programming 
limitations. But at this point in the project, we are not talking about design changes, 
merely changes to the way that the program does what the designer specified it should 
do. 


The development process is iterative, usually working at the module level. A 
programmer will usually follow this process: 


1. Code a module. 
2. Test a module for functionality. 
3. Make corrections to the module. 
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4. Repeat from step 2 until successful. 


Once testing has been completed on a module, it is signed off and effectively frozen to 
ensure that if changes are made to it later, it will be tested again. When sufficient 
modules have been coded and tested, they can be tested together in tests of 
ever-increasing complexity. 


This whole process repeats itself until all of the modules have been coded and tested. 
Although the process diagram shows testing only after development has been completed, 
testing is continuously occurring during the development phase. 


8.3.1 Tools for application development 
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On a day-to-day basis, the primary job of the programmer is to produce functioning, 
well-tested code. There are tools on the mainframe to assist in this process. The primary 
tool for the programmer is the editor. When developing traditional, procedural programs 
in languages such as COBOL and PL/I, the programmer often logs into TSO and uses the 
z/OS-based ISPF/PDF editor to modify code and JCL to compile, link/bind, and run the 
application. Source code is stored and managed in a common repository such as the IBM 
Software Configuration Library Manager (SCLM). The programmer uses the repository 
to store code that is under development or finalized, and can check in/out code and other 
artifacts so programmers do not interfere with each others’ work. 


Note: For purposes of simplicity, the source code could be stored and maintained in a 
partitioned data set (PDS). However, using a PDS would neither provide change 
control nor prevent multiple updates to the same version of code in the way that 
SCLM would. So, wherever we have written “checking out” or “saving” to SCLM, 
assume that you could substitute this with “edit a PDS member” or “save a PDS 
member.” 


When the programmer completes source code changes, a JCL file is submitted to compile 
the source code, bind the application modules, and create an executable for testing. 


Some of the application enablement services that are available on z/OS are: 


> IBM WebSphere Studio Enterprise Developer: Rapid construction of well-structured 
e-business systems integrating WebSphere and traditional transactional environments 
(CICS and IMS), visual construction of complex Web systems, and support for 
multiple databases, including IBM DB2. 

Language Environment 

C/C++ IBM Open Class Library 

DCE Application Support! 

Encina® Toolkit Executive2 

C/C++ with Debug Tool 

DFSORT 


vvvvvy 
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GDDM-PGF 

GDDM-REXX 

HLASM Toolkit 

Traditional languages such as COBOL, PL/I, and Fortran 


vvvy 


For more information, refer to Appendix 13, “Overview of IMS on z/OS”, Appendix 9, 
“Using programming languages on z/OS”, Appendix 15, “HTTP Server and WebSphere 
Application Server on z/OS” and Appendix 12, “Overview of CICS on z/OS”. 


8.3.2 Example of an application development debugging session 


The application programmer then conducts “unit tests,” which test the functionality of 
the particular module that they are working on. The programmer uses job monitoring and 
viewing software such as the System Display and Search Facility (SDSF) to track the 
running compile jobs, view the compiler/binder output, and verify the results of the unit 
tests. Then the programmer could make the appropriate corrections to source code or 
other objects. 


Sometimes, a program will create a “dump” of memory when a failure occurs. When this 
happens, the programmer can use tools such as the IBM Debug Tool and the IBM Fault 
Analyzer to interrogate the dump output and to trace through executing code to find the 
failure or misbehaving code. 


A typical development session follows these steps: 
> Log into TSO. 


> Enter ISPF/PDF and open/check out source code from the SCLM repository (or 
PDS). 


> Edit the source code to make necessary modifications. 
> Submit JCL to build the application and do a test run. 
> Switch to SDSF to view the running job status. 

> View the job output in SDSF to check for errors. 

> View the dump output to find bugs!. 

> Re-run the compile/link/go job and view the status. 

> Check the validity of the job output. 

> Save the source code in SCLM (or PDS). 


' The origin of the term “programming bug” is attributed to US Navy Lieutenant Grace Murray Hopper in 
1945. Lt. Hopper was testing the Mark II Aiken Relay Calculator at Harvard University. One day, a program 
that worked previously mysteriously failed. Upon inspection, the operator found that a moth was trapped 
between the circuit relay points and had created a short-circuit (early calculators occupied many square feet, 
and consisted of tens of thousands of vacuum tubes). The September 9, 1945 log included both the moth and the 
entry: “First actual case of a bug being found”, and that they had “debugged the machine”. 
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Some mainframe application programmers have now switched to the use of Interactive 
Development Environment (IDE) tools to accelerate the edit/compile/test process. IDEs 
such as the WebSphere Studio Enterprise Developer are used to edit source code on a 
workstation instead of directly on the host system, to run compiles “off-platform,” and to 
perform remote debugging. The use of the IDE is particularly useful if hybrid 
applications are being built that employ host-based programs in COBOL or transaction 
systems such as CICS and IMS, but also contain a Web browser-like user interface. The 
IDE provides a unified development environment to build both the on-line transaction 
processing (OLTP) components in a high-level language and the HTML front-end user 
interface components. Once the components are developed and tested, they are packaged 
into the appropriate deployment format and passed to the team that coordinates 
production code deployments. 


In addition to creating new application code, the application programmer is responsible 
for the maintenance and enhancement of existing mainframe applications. In fact, this is 
the primary job for many high-level language programmers on the mainframe today. 
While most customers do still create new programs with COBOL, PL/I, etc., languages 
such as Java have become popular for building new applications on the mainframe, just 
as on distributed platforms. 


However, for those of you interested in the traditional languages, there is still widespread 
development of programs on the mainframe in high-level languages such as COBOL and 
PL/I. There are many thousands of programs in production on mainframe systems around 
the world, and these programs are critical to the day-to-day business of the corporations 
that use them. COBOL and other high-level language programmers are needed to 
maintain existing code and make updates and modifications to those programs. Also, 
many corporations continue to build new application logic in COBOL and other 
traditional languages, and IBM continues to enhance the high-level language compilers 
to include new functions and features that allow these languages to continue to exploit 
newer technologies and data formats. 


8.4 System tests 
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The difference between the testing done at this stage and the testing done during the 
development phase is that we are now testing the application as a whole, as well as in 
conjunction with other applications. We also carry out tests that can only be done once 
the application coding has been completed because we need to know how the whole 
application performs, and not just a portion of it. 


The tests performed during this phase are: 


> User testing - The user tests the application for functionality and usability. 


> Integration testing - The new application is tested together with other applications to 
see if they interface as expected. 
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> Performance or stress testing - The application is tested using real production data or 
at least real production data volume to see how well the application performs when 
there is high demand. 


The results of the user and integration tests need to be verified to ensure that they are 
satisfactory. In addition, the performance of the application must match the requirements. 
Any issues coming out of these tests need to be addressed before going into production. 
The number of issues encountered during the testing phase are a good indication of how 
well we did our design work. 


8.5 Going into production 


The act of “going into production” is not simply turning on a switch that says now the 
application is production-ready. It is much more complicated than that. And from one 
project to the next, the way in which a program goes into production can change. 


In some cases, where we have an existing system that we are replacing, we might decide 
to run in parallel for a period of time prior to switching over to the new application. In 
this case, we run both the old and the new systems against the same data and then 
compare the results. If after a certain period of time we are satisfied with the results, we 
switch to the new application. If we discover problems, we can correct them and continue 
the parallel run until there aren’t any new problems. 


In other cases, we are dealing with a new system, and we might just have a cut-over day 
when we start using it. Even in the case of a new system, we are usually replacing some 
form of system, even if it’s a manual system, so we could still do a parallel test if we 
wanted to. 


Whichever method is used to go into production, there are still all of the loose ends that 
need to be taken care of before we hand the system over to Operations. One of the tasks is 
to provide documentation for the system, as well as procedures for running and using it. 
We need to train anyone who interacts with the system. 


When all of the documentation and training has been done, then we can hand over 
responsibility for the running of the application to Operations and responsibility for 
maintaining the application to the Maintenance group. In some cases, the Development 
group also maintains applications. 


8.5.1 Maintenance 


At this point, the application development lifecycle reaches a steady state and we enter 
the maintenance phase of the application. From this point onward, we only apply 
enhancements and day-to-day changes to the application. Since the application now falls 
under a change control process, all changes must be tested according to the process for 
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change control, before they are accepted into production. In this way, we can ensure a 
stable, running application for our users. 


8.6 Summary 
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This chapter describes the roles of the application designer and application programmer. 
The discussion is intended to highlight the types of decisions that are involved in 
designing and developing an application to run in the mainframe environment. This is not 
to say that the process is much different on other platforms, but some of the questions and 
conclusions can be different. 


This chapter then describes the lifecycle of designing and developing an application to 
run on z/OS. The process begins with the requirement gathering phase, in which the 
application designer attempts to identify the relevant parts of the problem to be solved. 
The designer analyzes user requirements to see how best to satisfy them. There may be 
many ways to arrive at the same solution; the object of the analysis and design phases is 
to ensure that the optimal solution is chosen. Here, “optimal” does not mean “quickest,” 
although time is an issue in any project. Instead, optimal refers to the best overall 
solution, with regard to user requirements and problem analysis. 


At the end of the design phase, the programmer’s role takes over. The programmer must 
now translate the application design into error-free program code. Throughout the 
development phase, the programmer tests the code as each module is added to the whole. 
The programmer must correct any logic problems that are detected and add the updated 
modules to the completed suite of tested programs. 


An application rarely exists in isolation. Rather, an application is usually part of a larger 
set of applications, where the output from one application is the input to the next 
application. To verify that a new application does not cause problems when incorporated 
into the larger set of applications, the application programmer conducts a system test or 
integration test. These tests are themselves designed, and many test results are verified by 
the actual application users. 


If there are problems with the system test, the problems will need to be resolved and the 
test repeated before the process can proceed to the next step. 


Following a successful system test, the application is ready to go into production. This 
phase is sometimes referred to as promoting an application. Once promoted, the 
application code is now more closely controlled. A business would not want to introduce 
a change into a working system without being sure of its reliability. At most z/OS sites, 
strict rules govern the promotion of applications (or modules within an application) to 
prevent untested code from contaminating a “pure” system. 
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At this point in the lifecycle of an application, it has reached a steady state. The only 
changes that will be made to a production application are enhancements, functional 
changes (for example, tax laws change, so payroll programs need to change), or 








corrections. 
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8.7 Discussion questions 


Gr eee 


Why should I select a zSeries environment in which to design an application? 
What are the differences between a designer and a programmer? 

Which role must have a global view of the entire project? 

What is the purpose for using a repository to manage source code? 


What are the phases in an application development lifecycle? 
Describe what happens in each phase. 


If you were a designer on a specific project and the timeline for getting the new 
application into production was very short, what decisions might you make in order 
to reduce the overall timeline of the project? 


As part of your system testing phase, you do a performance test on the application. 
Why would you use production data to do this test? 


Give some possible reasons for deciding to use batch for an application versus online. 


What are the roles of an application programmer? 


10. What are the roles of an application designer? 


11. Why would you use a cataloged procedure? 


12. Where did the term “programming bug” come from? 


13. What is an application? 


14. In which phase of the application development lifecycle does the designer conduct 


interviews? 
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15. Name some of the application enablement services that are available on z/OS. 
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8.8 Instructor notes 


Answers to “Discussion questions” on page 8-15: 


if 


Reasons for selecting a zSeries environment to design an application 


— Security 

— Support for many programming languages 
— Robust platform 

— Support for many applications 


Role of programmer versus role of designer 


— Programmers are programmers but designers do not need to be. A designer might 
not even interact with the mainframe environment directly, although the designer 
would need to be aware of the capabilities of the environment. 

— Programmers have a more local view of the project, whereas designers must have 
a global view. 

— Programmers write source code whereas designers determine what will go into 
the source code (using some sort of non-programming language). 


The designer must have a global view of the entire project in order to best determine 
how the various pieces of the puzzle fit together. The designer needs to interact with 
the users, the programmers, database specialists, operations, and other groups, so 
their role must have a global view. 


The purpose for using a repository to manage source code is: 


— To provide change control. 
— To prevent multiple programmers from updating the same source at the same time 
and wiping out each other’s changes. 


The phases of an application development lifecycle 
— Gather requirements 
User, hardware and software requirements 
— Analysis 
An iterative step where solutions are validated and revised before going on 
— Design 
¢ High-level design 
* Detailed design 
¢ Hand-off to programmers 
— Programmers code and test 


* Coding of source programs 
¢ Testing functionality of source programs 
¢ Revising source programs 
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— System testing 
* User —- 












s and ‘libraries. 
onsibility for the application to operations. 


renames 
* Hand-off 1 


— Maintenance 
* Perform ongoing maintenance and enhancements to applications as needed. 


6. For a designer, some decisions that can reduce the overall timeline of the project are: 





We will Hass off per rce cost versus is. a me 


— Using a software package instead of developing a solution 
We will trade off having a product that does exactly what we want for having one 
that does almost what we want. There may also be cost savings in purchasing a 
— : 





7. To doa meaningful performance test of an application, you must use actual 
production data. This is the only way to know how your application will perform 
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10. 


1, 


12. 


1. 


once it is in production. Using actual production data implies that not only should the 
content be the same as in production, but the volume should be the same as in 
production. 


Reasons for using batch or online 
— Reasons for using batch 


¢ Data is stored on tape. 
¢ Transactions are submitted for overnight processing. 
¢ User does not require online access to data. 


— Reasons for using online 


¢ User requires online access to data. 
¢ High response time requirements. 


The roles of an application programmer 


— Translate the designer’s requirements into source code 
— Test source code and make any necessary corrections 
— Maintain and enhance existing applications 


The roles of an application designer 


— Gather requirements 

— Analyze requirements 

— Create a high-level design 

— Create a detailed design 

— Hand over requirements to programmers 
— Oversee testing (user, system, integration) 
— Participate in going production 


You would use a cataloged procedure for JCL that is frequently used. There are 
several reasons for this: 


— It eliminates having to code the JCL each time it is used. 
— It ensures that each time the JCL is used, it is the same JCL (consistency). 


The origin of the term “programming bug” is attributed to US Navy Lieutenant Grace 
Murray Hopper in 1945. Lt. Hopper was testing the Mark II Aiken Relay Calculator 
at Harvard University. One day, a program that worked previously mysteriously 
failed. Upon inspection, the operator found that a moth was trapped between the 
circuit relay points and had created a short-circuit (early calculators occupied many 
square feet, and consisted of tens of thousands of vacuum tubes). The September 9, 
1945 log included both the moth and the entry: “First actual case of a bug being 
found”; and that they had “debugged the machine”. 


An application is a piece of software that satisfies certain specific requirements 
(resolves certain problems). The solution could reside on any platform or 
combination of platforms, from a hardware or operating system point of view. 
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14. The designer conducts interviews in the requirement gathering phase of the 
application development lifecycle. 
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9 


Using programming languages on 
z/OS 








Objective: A z/OS application developer needs to know which programming 
languages are supported on z/OS, and what factors influence the choice. 


In this chapter, you will learn: 


> Descriptions of several common programming languages for the 
mainframe: Assembler, COBOL, PL/I, C/C++, and Java 

> Differences between a compiled language and an interpreted language, 
with an overview of the REXX and CLIST interpreted languages 

















9.1 Overview of programming languages 


A computer language is the way that a human communicates with a computer. It is 
needed because a computer works only with its machine language (bits and bytes). This 
is slow and cumbersome for humans to use. Therefore, we write programs in a computer 
language, which then gets converted into machine language for the computer to process. 


There are many computer languages, and they have been evolving from machine 
language into a more natural way of writing. Some languages have been adapted to the 
kind of application that they intended to solve and to the kind of approach used in the 
design. The word generation has been used to indicate this evolution. 
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A classification of computer languages follows. 
1. Machine language, the lst generation, direct machine code. 


2. Assembler, 2nd generation, using mnemonics to present the instructions to be 
translated later into machine language by an assembly program, such as Assembler 
language. 


3. Procedural languages, 3rd generation, also known as high level languages (HLL), 
such as Pascal, FORTRAN, Algol, COBOL, PL/I, Basic, and C. The coded program, 
called a source program, has to be translated via a compilation step. 


4. Non-procedural languages, 4th generation, also known as 4GL, used for predefined 
functions in applications for databases, report generators, queries, such as RPG, CSP, 
QMF. 


5. Visual Programming languages that use a mouse and icons, such as VisualBasic and 
VisualC++. 


6. HyperText Markup Language, used for writing of World Wide Web documents. 
7. Object-Oriented language, OO technology, such as Smalltalk, Java, and C++. 


8. Other languages, for example 3D applications. 


Each computer language evolved separately, driven by the creation of and adaptation to 
new standards. In the following sections we describe several of the most widely used 
computer languages supported by z/OS: 


Assembler - “Using Assembler language on z/OS” on page 9-3 
COBOL - “Using COBOL on z/OS” on page 9-5 

PL/I - “Using PL/I on z/OS” on page 9-10 

C/C++ - “Using C/C++ on z/OS” on page 9-10 

Java - “Using Java on z/OS” on page 9-11 

CLIST - “Using CLISTs on z/OS” on page 9-11 

REXX - “Using REXX on z/OS” on page 9-12 


vvvvvvy 


For the computer languages just discussed, we have listed the evolution of computer 
languages and classified them. There are procedural and non-procedural, compiled and 
interpretive, and machine-dependent and non-machine-dependent languages. 


Assembler language programs are machine-dependent, because the language is a 
symbolic version of the machine’s language on which the program is running. As we can 
see in “Description” on page 9-14, Assembler language instructions change from one 
machine to another, so an Assembler language program written for one machine would 
not be portable to another. It would most likely need to be rewritten to take into account 
the instruction set of the other machine. A program written in a high-level language 
(HLL) would run on other platforms, but it would need to be recompiled into the machine 
language of the target platform. 
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Most of the HLLs that we touch upon in this chapter are procedural languages. This type 
is well-suited to writing structured programs. The non-procedural languages, such as 
SQL and RPG, are more suited for special purposes, such as report generation. 


Most HLLs are compiled into machine language, but some are interpreted. Those that are 
compiled result in machine code which is very efficient for repeated executions. 
Interpreted languages must be parsed, interpreted, and executed each time that the 
program is run. The trade-off for using interpreted languages is a decrease in programmer 
time, but an increase in machine resources. See Sections 9.9, “Compiled versus 
interpreted languages” on page 9-13, 9.10, “Advantages of compiled languages” on 
page 9-13, and 9.11, “Advantages of interpreted languages” on page 9-13 for more 
information on this topic. 


9.2 Using Assembler language on z/OS 


Assembler language is a symbolic programming language that can be used to code 
instructions instead of coding in machine language. It is the symbolic programming 
language that is closest to the machine language in form and content. Therefore, 
Assembler language is an excellent candidate for writing programs in which: 


> You need control of your program, down to the byte or bit level. 


> You must write subroutines! for functions that are not provided by other symbolic 
programming languages, such as COBOL, FORTRAN, or PL/I. 


Assembler language is made up of statements that represent either instructions or 
comments. The instruction statements are the working part of the language, and they are 
divided into the following three groups: 


> A machine instruction is the symbolic representation of a machine language 
instruction of the following instruction sets: 


— IBM System/360 

— IBM System/370 

— IBM System/370 Extended Architecture (370-XA) 

— IBM Enterprise Systems Architecture/370 (ESA/370) 
— IBM Enterprise Systems Architecture/390 (ESA/390) 
— IBM z/Architecture 


It is called a machine instruction because the assembler translates it into the machine 
language code that the computer can execute. 


> An assembler instruction is a request to the assembler to do certain operations during 
the assembly of a source module; for example, defining data constants, reserving 
storage areas, and defining the end of the source module. 


' Subroutines are programs that are invoked frequently by other programs and by definition should be written 
with performance in mind. Assembler language is a good choice for a subroutine. 
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> A macro instruction is a request to the assembler program to process a predefined 
sequence of instructions called a macro definition. From this definition, the assembler 
generates machine and assembler instructions, which it then processes as if they were 
part of the original input in the source module. 


The assembler produces a program listing containing all the information that it generated 
during the various phases of the assembly process. It is really a compiler for Assembler 
language programs. 


The assembler also produces information for other processors, such as the linker. Before 
the computer can execute your program, the object code has to be run through another 
process in order to resolve the addresses where instructions and data will be located. This 
process is called linkage editing and is performed by a linker. 


The linker, binder, or linkage editor (for more details, see 10.3.7, “Linkage editor” on 
page 10-14) uses information in the object modules to combine them into load modules. 
At program fetch time, the load module produced by the linker is loaded into virtual 
storage. After the program is loaded, it can be run. 


Figure 9-1 on page 9-5 illustrates these steps. 
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Figure 9-1 Assembler source to executable module 


For more information, refer to the following publications: 


> HLASM General Information, GC26-4943 
> HLASM Installation and Customization Guide, SC26-3494 
> HLASM Language Reference, SC26-4940 


You can find these manuals at the following Web site: 


http://www. ibm.com/servers/eserver/zseries/zos/bkserv/find_shelves.html 


9.3 Using COBOL on z/OS 


Common Business-Oriented Language (COBOL) is a programming language similar to 
English that is widely used to develop business-oriented applications in the area of 
commercial data processing. COBOL has been almost a generic term for computer 
programming in this kind of computer language. However, as used in this chapter, 
COBOL refers to the product IBM Enterprise COBOL for z/OS and OS/390. 
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In addition to the traditional characteristics provided by the COBOL language, this 
version of COBOL is capable, through COBOL functions, of integrating COBOL 
applications into Web-oriented business processes. With the capabilities of this release, 
applications developers can do the following: 


> Utilize new debugging functions in Debug Tool 


> Enable interoperability with Java when an application runs in an IMS Java dependent 
region 

> Simplify the componentization of COBOL programs and enable interoperability with 
Java components across distributed applications 


> Promote the exchange and usage of data in standardized formats including XML and 
Unicode 


With Enterprise COBOL for z/OS and OS/390, COBOL and Java applications can 
interoperate in the e-business world. 


The COBOL compiler produces a program listing containing all the information that it 
generated during the compilation. The compiler also produces information for other 
processors, such as the linker. 


Before the computer can execute your program, the object code has to be run through 
another process in order to resolve the addresses where instructions and data will be 
located. This process is called linkage edition and is performed by a linker. 


The linker, binder or linkage editor (for more details, see 10.3.7, “Linkage editor” on 
page 10-14) uses information in the object modules to combine them into load modules. 
At program fetch time, the load module produced by the linker is loaded into virtual 
storage. When the program is loaded, it can then be run. Figure 9-2 on page 9-7 
illustrates the process of translating the COBOL source language statements into an 
executable load module. 


This process is similar to that of Assembler language programs. In fact, this same process 
is used for all of the HLLs that are compiled. 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter9 languages.fm 





HLL 


source statements 






HLL compiler 





Machine language 








Messages 
a version of the 
listings = prog reli 


pe 





Executable 


load module 











Figure 9-2 HLL source to executable module 


9.3.1 COBOL relationship between JCL and program files 


Example 9-1 depicts the relationship between JCL statements and the files in a COBOL 
program. By not referring to physical locations of data files in a program, we achieve 
device independence. That is, we can change where the data resides and what it is called 
without having to change the program. We would only need to change the JCL. 


Example 9-1 COBOL relationship between JCL and program files 


//MYJOB JOB 
//STEP1 EXEC IGYWCLG 


INPUT-OUTPUT SECTION. 
FILE-CONTROL. 
SELECT INPUT ASSIGN TO INPUT1 ..... 
SELECT DISKOUT ASSIGN TO OUTPUT1 ... 
FILE SECTION. 
FD INPUT1 
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BLOCK CONTAINS... 
DATA RECORD IS RECORD-IN 
01 INPUT-RECORD 


FD OUTPUT1 
DATA RECORD IS RECOUT 
01 OUTPUT-RECORD 
la 
//GO.INPUT1 DD DSN=MY.INPUT,DISP=SHR 
//GO.OUTPUT1 DD DSN=MY.OUTPUT ,DISP=OLD 


Example 9-1 shows a COBOL compile, link, and go job stream, listing the file program 
statements and the JCL statements to which they refer. 


The COBOL SELECT statements make the links between the DDNAMEs INPUT1 and 
OUTPUT1, and the COBOL FDs INPUTI and OUTPUT1, respectively. The COBOL 
FDs are associated with group items INPUT-RECORD and OUTPUT-RECORD. 


The DD cards INPUT1 and OUTPUT! are related to the data sets MY.INPUT and 
MY.OUTPUT, respectively. The end result of this linkage in our example is that records 
read from the file INPUT will be read from the physical data set MY.INPUT and 
records written to the file OUTPUT1 will be written to the physical data set 
MY.OUTPUT. The program is completely independent of the location of the data and the 
name of the data sets. 


Figure 9-3 shows the relationship between the physical data set, the JCL, and the 
program for Example 9-1. Once again, since the program does not make any reference to 
the physical data set, we would not need to recompile the program if the name of the data 
set or its location were to change. 





DDNAME DSNAME 


Progra JCL for JOB 


/NNPUT1 DD DSNAME=MY.INPUT MY.INPUT 


Figure 9-3 Relationship between JCL, program, and data set 


OPEN FILE=INPUT1 
READ FILE=INPUT1 


CLOSE FILE=INPUT1 
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9.3.2 HLL relationship between JCL and program files 


In 9.3.1, “COBOL relationship between JCL and program files” on page 9-7, we 
illustrated how you can isolate your COBOL program from changes in data set name and 
data set location. However, the technique of referring to physical files by a symbolic file 
name is not restricted to COBOL. This technique is used by all HLLs and even by 
Assembler language. Refer to Example 9-2 for a generic HLL example of a program that 
references data sets by using symbolic file names. 


Isolating your program from changes to data set name and location is the normal 
objective. However, there could be cases when a program would need to access a specific 
data set at a specific location on DASD. This could be accomplished by using Assembler 
language or even by using some of the HLLs. 


The practice of “hard-coding” data set names or other such information in a program is 
not usually considered a good programming practice. Values that are hard-coded in a 
program are subject to change and would therefore require that your program be 
recompiled each time one of these values changed. Externalizing these values from 
programs, such as is the case of referring to data sets within a program by a symbolic 
name, is a more effective practice that allows the same program to work even if the data 
set name changes. 


Example 9-2 HLL Relationship between JCL and program files 


//MYJOB JOB 
//STEP1 EXEC CLG 


OPEN FILE=INPUT1 
OPEN FILE=OUTPUT1 
READ FILE=INPUT1 


WRITE FILE=OUTPUT1 


CLOSE FILE=INPUT1 

CLOSE FILE=OUTPUT1 
/* 
//GO.INPUT1 DD DSN=MY.INPUT,DISP=SHR 
//GO.OUTPUT1 DD DSN=MY .OUTPUT,DISP=OLD 


Refer to 5.4, “Symbolic file system” on page 5-4 for a more detailed explanation of using 
a symbolic name to refer to a file. 


For more information, refer to the following manuals: 


> Enterprise COBOL for z/OS and OS/390 V3R2 Language Reference, SC27-1408 
> Enterprise COBOL for z/OS and OS/390 V3R2 Programming Guide, SC27-1412 
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You can find these manuals on the following Web site: 


http://www. ibm. com/servers/eserver/zseries/zos/bkserv/find_shelves.html 


9.4 Using PL/I on 2/OS 


Programming Language/I (PL/I, pronounced “P-L one”), is a _ full function, 
general-purpose, high-level programming language suitable for the development of: 

> Operating systems 

> Commercial applications 

> Engineering/scientific applications 

> Many other applications 


PL/I programs are made up of blocks. A block can be either a subroutine or just a group 
of statements. A PL/I block allows you to produce highly-modular applications. 


The process of compiling a PL/I source program and then link-editing the object code 
into a load module is basically the same as it is for COBOL. Refer to Example 9-2 on 
page 9-7, 10.3.7, “Linkage editor” on page 10-14 and Figure 9-3 on page 9-8. 


The relationship between JCL and program files is the same for PL/I as it is for COBOL 
and other HLLs. Refer to Figure 9-3 on page 9-8 and to Example 9-2 on page 9-9. 


For more information, refer to the following manuals: 
> Enterprise PL/I for z/OS V3R3 Language Reference, SC27-1460 

> Enterprise PL/I for z/OS V3R3 Programming Guide, SC27-1457 

You can find these manuals on the following Web site: 


http://www. ibm. com/servers/eserver/zseries/zos/bkserv/find_shelves.html 


9.5 Using C/C++ on Z/OS 
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C is a programming language designed for a wide variety of programming tasks. It is 
used for: 


System-level code 

Text processing 

Graphics 

Many other application areas 


vvvy 


The C language contains a concise set of statements with functionality added through its 
library. This division enables C to be both flexible and efficient. An additional benefit is 
that the language is highly consistent across different systems. 
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The process of compiling a C source program and then link-editing the object code into a 
load module is basically the same as it is for COBOL. Refer to Example 9-2 on page 9-7, 
10.3.7, “Linkage editor” on page 10-14, and Figure 9-3 on page 9-8 to see this process. 


The relationship between JCL and program files is the same for PL/I as it is for COBOL 
and other HLLs. Refer to Figure 9-3 on page 9-8 and to Example 9-2 on page 9-9. 


For more information, refer to the following manuals: 
> C/C++ Language Reference, SC09-4764 
> C/C++ Programming Guide, SC09-4765 














You can find these manuals on the following Web site: 


http://www. ibm. com/servers/eserver/zseries/zos/bkserv/find_shelves.html 


9.6 Using Java on z/OS 


Java is an object-oriented programming language developed by Sun Microsystems Inc. 
Programming languages such as Enterprise COBOL and Enterprise PL/I in z/OS provide 
interfaces to programs written in Java Language. 


9.7 Using CLISTs on 2/OS 


The CLIST language is an interpreted language. Like programs in other high-level 
interpreted languages, CLISTs are easy to write and test. You don't have to compile and 
link-edit them. To test a CLIST, you execute it, correct any errors, and re-execute it. 


The CLIST and REXX languages are the two command languages available from 
TSO/E. The CLIST language enables you to work more efficiently with TSO/E. 


The term CLIST (pronounced “see list”) stands for command list; it is called this because 
the most basic CLISTs are lists of TSO/E commands. When you invoke such a CLIST, it 
issues the TSO/E commands in sequence. 

The CLIST programming language is used for: 

> Performing routine tasks (such as entering TSO/E commands) 

> Invoking other CLISTs 

> Invoking applications written in other languages 

> ISPF applications (such as displaying panels and controlling application flow) 


> One-time quick solutions to problems 
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9.8 Using REXX on 2/OS 
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The Restructured Extended Executor (REXX) language is a procedural language that 
allows programs and algorithms to be written in a clear and structural way. It is an 
interpreted and compiled language. An interpreted language is different from other 
programming languages, such as COBOL, because it is not necessary to compile a 
REXX command list before executing it. However, you can choose to compile a REXX 
command list before executing it to reduce processing time. 


The REXX programming language can be used for: 

> Performing routine tasks (such as entering TSO/E commands) 

> Invoking other REXXs 

> Invoking applications written in other languages 

> ISPF applications (displaying panels and controlling application flow) 
> One-time quick solutions to problems 

> System programming 


> Wherever we can use another HLL compiled language 


REXX is also used in the Java environment. A new dialect of REXX called NetRexx 
works seamlessly with Java. NetRexx programs can use any Java classes directly, and 
can be used for writing any Java class. This brings Java security and performance to 
REXX programs, and REXX arithmetic and simplicity to Java. A single language, 
NetRexx, may be used for both scripting and application development. 


The process of compiling a REXX source program and then link-editing the object code 
into a load module is basically the same as it is for COBOL. Refer to Example 9-2 on 
page 9-7, 10.3.7, “Linkage editor” on page 10-14 and Figure 9-3 on page 9-8 to see this 
process. 


The relationship between JCL and program files is the same for REXX as it is for 
COBOL and other HLLs. Refer to Figure 9-3 on page 9-8 and to Example 9-2 on 
page 9-9. 


A REXX program compiled under z/OS can run under z/VM. Similarly, a REXX 
program compiled under z/VM can run under z/OS. A REXX program compiled under 
z/OS or z/VM can run under VSE/ESA if REXX/VSE is installed. 


For more information, refer to the following publications: 
> The REXX Language, 2nd Ed., Cowlishaw, ZB35-5100 

> Procedures Language Reference (Level 1), C26-4358 SAA CPI 

> REXX on zSeries VIR4.0 User's Guide and Reference, SH19-8160 

> Creating Java Applications Using NetRexx , SG24-2216 
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For more information, refer to the following Web site: 


http: //www-306. ibm. com/software/awdtools/REXX/1anguage/REXX1inks.html 


9.9 Compiled versus interpreted languages 


You need to decide whether to use a compiled language or an interpreted language in the 
design stage. Both compiled and interpreted languages have their strengths and 
weaknesses. Usually, a decision to use an interpreted language is made because of time 
restrictions on development or for ease of future changes to the program. A trade-off is 
made when using an interpreted language. You trade speed of development for higher 
execution costs. Since each line of an interpreted program must be translated each time it 
is executed, there is a higher overhead. Hence, they are generally more suited to ad hoc 
requests versus non-ad hoc. This topic is discussed in more detail in 9.7, “Using CLISTs 
on z/OS” on page 9-11. 


9.10 Advantages of compiled languages 


Assembler, COBOL, PL/I, C/C++ are all translated by running the source code through a 
compiler. This results in very efficient code that can be executed any number of times. 
The overhead for the translation is incurred just once, when the source is compiled; 
thereafter, it need only be loaded and executed. 


Interpreted languages, in contrast, must be parsed, interpreted, and executed each time 
the program is run, thereby greatly adding to the cost of running the program. For this 
reason, interpreted programs are usually less efficient than compiled programs. 


Some programming languages, such as REXX and Java, can be either interpreted or 
compiled. 


9.11 Advantages of interpreted languages 


In “Advantages of compiled languages” we discussed the reasons for using languages 
that are compiled. In “Using CLISTs on z/OS” and “Using REXX on z/OS” we discussed 
the strong points of interpreted languages. There is no simple answer as to which 
language is “better’—it depends on the application. Even within an application we could 
end up using many different languages. For example, one of the strengths of a language 
like CLIST is that it is easy to code, test, and change. However, it is not very efficient. 
The trade-off is machine resources for programmer time. 


Keeping this in mind, we can see that it would make sense to use a compiled language for 
the intensive parts of an application (heavy resource usage), whereas interfaces (invoking 
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the application) and less-intensive parts could be written in an interpreted language. An 
interpreted language might also be suited for ad hoc requests or even for prototyping an 
application. 


One of the jobs of a designer is to weigh the strengths and weaknesses of each language 
and then decide which part of an application is best suited for a particular language. 


9.12 Overview of Language Environment 


The goals of application development include modularizing and sharing code, and 
developing applications on a workstation-based front end. On z/OS, the Language 
Environment product provides a common environment for all conforming high-level 
language (HLL) products. An HLL is a programming language above the level of 
assembler language and below that of program generators and query languages. 


Language Environment establishes a common language development and execution 
environment for application programmers on z/OS and z/VM _ systems. Whereas 
functions were previously provided in individual language products, Language 
Environment eliminates the need to maintain separate language libraries. 


9.12.1 Description 


In the past, programming languages had limited ability to call each other and behave 
consistently across different operating systems. This characteristic constrained programs 
that wanted to use several languages in an application. Programming languages had 
different rules for implementing data structures and condition handling, and for 
interfacing with system services and library routines. By having the ability to easily and 
seemlessly call one language from another, programmers can exploit the functions and 
features in each language. 


9.12.2 Application program 
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An application is a collection of one or more programs cooperating to achieve particular 
objectives, such as inventory control or payroll. 


Language Environment establishes a common run-time environment for all participating 
HLLs. It combines essential run-time services, such as routines for run-time message 
handling, condition handling, and storage management. All of these services are 
available through a set of interfaces that are consistent across programming languages. 
You may either call these interfaces yourself, or use language-specific services that call 
the interfaces. With Language Environment, you can use one run-time environment for 
your applications, regardless of the application's programming language or system 
resource needs. 
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Figure 9-4 shows the components in the Language Environment, consisting of: 


> Basic routines that support starting and stopping programs, allocating storage, 
communicating with programs written in different languages, and indicating and 
handling conditions. 


> Common library services, such as math or date and time services, that are commonly 
needed by programs running on the system. These functions are supported through a 
library of callable services. 


> Language-specific portions of the run-time library. 








C/C++ COBOL FORTRAN PL/I 
language- language- language- language- 
specific specific specific specific 
library library library library 





Language Environment callable service interface, common 


services, and support routines 








Figure 9-4 z/OS Language Environment components 


z/OS Language Environment is the prerequisite run-time environment for applications 
generated with the following IBM compiler products: 


z/OS C/C++ 

C/C++ Compiler for z/OS 

AD/Cycle C/370 Compiler 

VisualAge for Java, Enterprise Edition for OS/390 

Enterprise COBOL for z/OS and OS/390 

COBOL for z/OS 

Enterprise PL/I for z/OS and OS/390 

PL/I for MVS & VM (formerly AD/Cycle PL/I for MVS & VM) 
VS FORTRAN and FORTRAN IV (in compatibility mode) 


vvvvvvvvy 


In many cases, you can run compiled code generated from the previous versions of the 
above compilers. A set of assembler macros is also provided to allow assembler routines 
to run with Language Environment. 
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9.13 Summary 
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This chapter gives you an idea of the many decisions you need to make when you design 
and develop an application. Deciding on which language to use is an important step in the 
design phase of an application. A developer/designer must be aware of the strengths as 
well as the weaknesses of each language in order to make the best choice, based on the 
particular requirements of the application. 


A critical factor in choosing a language is determining which one is most used at a given 
installation. If COBOL is used for most of the applications in an installation, then it will 
likely be the language of choice for new applications as well. 


Keep in mind, however, that even when a choice for the primary language is made, it 
does not mean that you are locked into that choice for all programs within the 
application. There might be a case for using multiple languages, so as to take advantage 
of the strengths of a particular language for certain parts of the application. Such a case 
might be to write subroutines that are invoked frequently in Assembler language so that 
they are more efficient. Even if the rest of the application were written in COBOL, we 
could still have subroutines written in Assembler or some other language. 


Many installations maintain a library of subroutines that are shared across the 
installation. These might include, for example, date conversion routines. As long as these 
subroutines are written using standard linkage conventions, they can be called from other 
languages without being aware of the language that the subroutines are written in. 


The bottom line is that each language has inherent strengths, and applications should be 
written to exploit these strengths. If a given application warrants the added complication 
of writing it in multiple languages, then take advantage of the language features. But 
keep in mind that when it is time to maintain the application, you will need people who 
are capable of programming in all of these languages. This is a cardinal rule of 
programming. The original programmer might be long gone, but the application will live 
on and on. This is why complexity in design must be weighed against ease of 
maintenance. 











Key terms in this chapter 

assembler compiler debugging 
dynamic link library generation 1/O (input/output) 
interpreter link editor load modules 
pre-processor programming language _ variable 
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9.14 Discussion questions 


1. 
a 


Ta eS 


10. 
11. 


12. 


Why might a program be written in Assembler language? 

Is IBM or any other company doing any development work for COBOL and PL/I 
languages? 

If you have to develop a transaction system, what is your best choice? 


a. COBOL or PL/I on CICS 
b. C/C++ on CICS 
c. A combination of the two above 


Why are CLIST and REXX called interpreted languages? 
What are the main areas of suitability for CLISTs and REXX? 
Is the use of Language Environment mandatory in z/OS application development? 


What is the skill level that an application programmer should have with respect to 
Language Environment? Is Language Environment something that should be handled 
by a system programmer? 


Which of the data file organizations are appropriate for online applications? 
Which of the data file organizations are appropriate for batch applications? 
What are some of the advantages of writing in an HLL versus Assembler language? 


Explain the relationship between a data set name, a DD name, and the file name 
within a program. 


Assume that program PROGI is run using the JCL below: 


//job JOB 

//STEPO10 EXEC PGM=PROG1 

//STEPLIB DD DSN=MY.PROGLIB,DISP=SHR 
//INPUT1 DD DSN=A.B.C,DISP=SHR 
//OUTPUT1 DD DSN=X.Y.Z,DISP=SHR 


If the INPUT1 DD card were changed to use the data set A1.B1.C1, would we be able 
to use the same program to process it? Assume that the new data set has the same 
characteristics as the old data set. 


9.15 Exercises 


1; 


If performance is a consideration, should you write a program in a compiled language 
or an interpreted language? 


Which language would you use to write an application that calculated premiums on 
an insurance policy? Assume that this application will be invoked by many other 
applications. 
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3. What is an HLL? 


4. Under what circumstances would you need to run your source program through a 
pre-compiler? 


5. Which interpreted language can also be compiled? 
6. Where does the name CLIST come from? 


7. Cana COBOL program call an Assembler language program? Why would you want 
to have this capability? 
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9.16 Instructor notes 


9.16.1 Answers to 9.14, “Discussion questions” on page 9-17 


L, 


Higher level languages cannot have access to privileged instructions and to certain 
specific hardware components. 


In the case of IBM, yes, for example the support for zSeries and the maintenance of 
compatibility with previous architectures. 


The best choice is C, where you can have a combination. This always depends, of 
course, on the environment and variables such as volumes and hardware support. All 
the EXEC CICS commands available in COBOL, PL/I, and Assembler language 
applications are also supported in C and C++ applications, with the exception of those 
commands related to non-structured exception handling. 


Because they can execute without a compilation step, and the instructions are parsed, 
interpreted and executed one-by-one. 


They are used for tailoring operating systems and for prototype development. They 
can also be used as a command language, i.e., CLISTs can be used to enter a group of 
TSO/E commands without having to retype them each time. 


In general, no. Languages have built-in functions that perform similar functions or 
services to those provided by Language Environment. It is definitely not for 
pre-Language Environment programs. However, some products clearly establish it as 
a requirement. 


Application programmers should be aware of what their program needs to do 
(services or functions), and what is available through Language Environment. The 
maintenance and processes for Language Environment are a matter for the system 
programmer. 


Online applications usually have requirements for short response times. Therefore, 
you would choose data file organizations that are indexed to permit fast access to 
data: 


— DBMS 
— VSAM 
— DB2 


Batch applications usually process records sequentially, but this is not always the 
case. They do not have the response time requirements of online applications, so the 
data file organization should be based on how the batch application accesses data - 
randomly or sequentially. If it accesses data randomly, then the data would require an 
index (as in online applications). Otherwise, the data could be stored as a flat file. 


. Some of the advantages of writing in an HLL versus writing in Assembler language 


are: 


Chapter 9. Using programming languages on Z/OS_ 9-19 


Chapter9 languages.fm Draft Document for Review December 3, 2004 3:15 pm 


— Reduced development time. 

— Ease of maintenance. 

— Application portability (HLLs are not machine-specific). You need to recompile 
and re-link in order to have the load module in the machine language of the new 
platform. 


11. The relationship between a data set name, a DD name, and the file name within a 


program is as follows: 


— The data set name is the name of the physical data set on DASD. 

— The DD name is the name on the JCL statement containing the data set. 

— The file name in the program refers to the DD name, and this completes the link 
from the program to the physical data set. 


12. Yes, we would be able to use the same program. Since the program does not refer 


explicitly to the data set by name, we can change the data set name or location to 
anything without changing the program as long as the characteristics of the new data 
set correspond with those of the old data set. 


9.16.2 Answers to “Exercises” on page 9-17 


1. 


A compiled language. Interpreted languages are less efficient because they must be 
parsed, interpreted and executed for each instruction that is processed. 


When an application is repeatedly invoked by other applications, we usually consider 
the performance of the invoked application. If this subroutine caused a system’s batch 
window? to extend into the online window’, then clearly we would want to write the 
subroutine in a more efficient language, like Assembler language. 


Examples: mathematical calculations being performed, or applications called many 
times by other programs. 


An HLL is a high-level language, such as COBOL, PL/I, Pascal, etc. These languages 
are procedural languages, called 3rd generation. 


If your source program has CICS Command Language calls or SQL calls, then you 
would need to run it through a pre-compiler. 


REXxX is an interpreted language and it also can be compiled. 


The name CLIST stands for Command List and it refers to the fact that CLISTs can be 
used to execute TSO/E commands, therefore a command list. 


Yes, a COBOL program can call an Assembler language program or almost any other 
language program as well, as long as standard linkage conventions are followed. You 
would want this capability in order to take advantage of the strengths of Assembler 
(or whatever the language of the called program), that is performance, or the ability to 
manipulate data at the byte level or bit level. 


> The time period when the online systems are down in order to allow batch processes to run. 
3 The time period when the online systems are up. 
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9.16.3 Demonstrations 


Viewing sample programs 


1 


10. 


Look at the following data set for a complex Assembler language program: 


ZPROF .LANG. SOURCE (ASMLE) 
This example establishes an environment and prints out the message “IN THE 
MAIN ROUTINE”. 


Look at the following data set for a simple Assembler language program: 


ZPROF .LANG. SOURCE (ASM) 
This example sets the return to 15 and exits. 


Look at the following data set for a complex C language program: 


ZPROF .LANG. SOURCE (C) 
This example establishes an environment and prints out the local date and 
time. 


Look at the following data set for a simple C language program: 


ZPROF .LANG. SOURCE (C2) 
This example prints out the message “Hello World”. 


Look at the following data set for a complex COBOL language program: 


ZPROF .LANG. SOURCE (COBOL) 
This example establishes an environment and prints out the local date and 
time. 


Look at the following data set for a simple COBOL language program: 


ZPROF .LANG. SOURCE (COBOL2) 
This example prints out the message “HELLO WORLD”. 


Look at the following data set for a complex PL/I language program: 


ZPROF .LANG. SOURCE (PL1) 
This example establishes an environment and prints out the local date and 
time. 


Look at the following data set for a simple PL/I language program: 


ZPROF .LANG. SOURCE (PL12) 
This example prints out the message “HELLO WORLD”. 


Look at the following data set for a complex CLIST language program: 


ZPROF .LANG. SOURCE (CLIST) 
This example prompts the user for a high-level qualifier (HLQ) and then 
produces a formatted catalog listing for that HLQ. 


Look at the following data set for a simple CLIST language program: 


ZPROF .LANG. SOURCE (CLIST2) 
This example prints out the message “HELLO WORLD”. 


Chapter 9. Using programming languages on Z/OS_ = 9-21 


Chapter9 languages.fm Draft Document for Review December 3, 2004 3:15 pm 


11. Look at the following data set for a complex REXX language program: 


ZPROF .LANG. SOURCE (REXX) 
This example prompts the user for a high-level qualifier (HLQ) and then 
produces a formatted catalog listing for that HLQ. 


12. Look at the following data set for a simple REXX language program: 


ZPROF .LANG. SOURCE (REXX2) 
This example prints out the message “HELLO WORLD”. 


9.16.4 More information about Assembler language 
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Processing sequence 

Processing involves the translation of source statements into machine language, 
assignment of storage locations to instructions and other elements of the program, and 
performance of auxiliary assembler functions you have designated. 


The output of the assembler program is the object program, a machine language 
translation of the source program. The assembler produces a printed listing of the source 
statements and object program statements, as well as additional information such as error 
messages that are useful in analyzing the program. The object program is in the format 
required by the linker. 


The assembler processes the machine and Assembler language instructions at different 
times during its processing sequence. The programmer should be aware of the 
assembler's processing sequence in order to code the program correctly. The assembler 
processes most instructions twice, first during conditional assembly and later, at 
assembly time. However, as described in the following section, it does some processing 
only during conditional assembly. 


Conditional assembly and macro instructions 

The assembler processes conditional assembly instructions and macro processing 
instructions during conditional assembly. During this processing, the assembler evaluates 
arithmetic, logical, and character conditional assembly expressions. Conditional 
assembly takes place before assembly time. 


The assembler processes the machine and ordinary assembler instructions generated from 
a macro definition called by a macro instruction at assembly time. 


Machine instructions 


The assembler processes all machine instructions, and translates them into object code at 
assembly time. 
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Assembler instructions 

The assembler processes ordinary assembler instructions at assembly time. During this 

processing: 

> The assembler evaluates absolute and relocatable expressions (sometimes called 
assembly-time expressions). 

> Some instructions, such as ADATA, ALIAS, CATTR and XATTR, DC, DS, ENTRY, 


EXTRN, PUNCH, and REPRO, produce output for later processing by programs 
such as the linker. 


Input/Output (I/O) 


The terms input (I) and output (O) are used to describe the transfer of data between I/O 
devices and main storage. An operation involving this kind of transfer is referred to as an 
I/O operation. The facilities used to control I/O operations are collectively called the 
channel subsystem (I/O devices and their control units attached to the channel 
subsystem). 


The channel subsystem directs the flow of information between I/O devices and main 
storage. It relieves CPUs of the task of communicating directly with I/O devices, and 
permits data processing to proceed concurrently with I/O processing. 


V/O devices 


An input/output (I/O) device provides external storage, a means of communication 
between data-processing systems, or a means of communication between a system and its 
environment. I/O devices include such equipment as magnetic-tape units, direct access 
storage devices (for example, disks), display units, typewriter-keyboard devices, 
printers, teleprocessing devices, and sensor-based equipment. An I/O device may be 
physically distinct equipment, or it may share equipment with other I/O devices. 


The term I/O device as used in this book refers to an entity with which the channel 
subsystem can directly communicate. 


9.16.5 More information about the COBOL language 


Standards 
The COBOL language complies to ISO standards. 


Input and output files 


Input and output files are defined in the INPUT-OUTPUT section of the 
ENVIRONMENT DIVISION. 
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Data structure: data items and group items 

Related data items can be parts of a hierarchical data structure. A data item that does not 
have any subordinate items is called an elementary data item. A data item that is 
composed of subordinated data items is called a group item. A record can be either an 
elementary data item or a group of data items. 


COBOL program types 

A COBOL source program is a syntactically correct set of COBOL statements. COBOL 
programs can be of different types: 

> Nested program, a program that is contained in another program. 


> Object program, a set or group of executable machine language instructions and other 
material designed to interact with data to provide problem solutions. An object 
program is generally the machine language result of the operation of a COBOL 
compiler on a source program. 


> Run unit, one or more object programs that interact with one another and that function 
at run time as an entity to provide problem solutions. 


> Sibling program, a nested program that is at the same nesting level as another nested 
program in the same containing program. 


COBOL program format 


The COBOL source statements are generally divided up into the following divisions: 


With the exception of the COPY and REPLACE statements and the end program marker, 
the statements, entries, paragraphs, and sections of a COBOL source program are 
grouped into the following four divisions: 


> IDENTIFICATION DIVISION, which identifies the program with a name and, if 
you want, gives other identifying information. 

> ENVIRONMENT DIVISION, where you describe the aspects of your program that 
depend on the computing environment. 

> DATA DIVISION, where the characteristics of your data are defined. These are 
defined in one of the following sections in the DATA DIVISION: 


— FILE SECTION, to define data used in input-output operations 

— LINKAGE SECTION, to describe data from another program. 

When defining data developed for internal processing: 

— WORKING-STORAGE SECTION, to have storage statically allocated and 
remain for the life of the run unit. 

— LOCAL-STORAGE SECTION, to have storage allocated each time a program is 
called and de-allocated when the program ends. 


— LINKAGE SECTION, to describe data from another program. 
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> PROCEDURE DIVISION, where the instructions related to the manipulation of 
data and interfaces with other procedures are specified. 


The PROCEDURE DIVISION ofa program is divided into sections and paragraphs, 
which contain sentences and statements, as described here: 


Section - a logical subdivision of your processing logic. A section has a section 
header and is optionally followed by one or more paragraphs. A section can be the 
subject of a PERFORM statement. One type of section is for declaratives. 


Declaratives are a set of one or more special purpose sections, written at the 
beginning of the Procedure Division, the first of which is preceded by the key 
word DECLARATIVES and the last of which is followed by the key word END 
DECLARATIVES. 


Paragraph - a subdivision of a section, procedure, or program. A paragraph can 
be the subject of a statement. 


Sentence - is a series of one or more COBOL statements ending with a period. 


Statement - performs a defined step of COBOL processing, such as adding two 
numbers. 


Phrase - a subdivision of a statement. 


Examples of COBOL divisions 
Example 9-3 IDENTIFICATION DIVISION 


IDENTIFICATION DIVISION. 

Program-ID. Helloprog. 

Author. A. Programmer. 

Installation. Computing Laboratories. 
Date-Written. 08/21/2002. 





Example 9-4 ENVIRONMENT DIVISION 





ENVIRONMENT DIVISION. 





CONFIGURATION SECTION. 


SOURCE-COMPUTI 
OBJECT-COMPUT! 
SPECIAL-NAMES. 








R. computer-name. 
R. computer-name. 





| 








special-names-entries. 





INPUT-OUTPUT SECTION. 








FILE 





L=0= 





-CONTROL. 
SELECT [OPTIONAL] file-name-1 
ASSIGN TO system-name [FOR MULTIPLE {REEL | UNIT}] 





























CONTROL. 
SAME [RECORD] AREA FOR file-name-1 ... file-name-n. 














Chapter 9. Using programming languages on z/OS 9-25 


Chapter9 languages.fm Draft Document for Review December 3, 2004 3:15 pm 


Example of input-output coding 
Explanations of the user-supplied information follow Example 9-5. 


Example 9-5 Input and output files in FILE-CONTROL 
IDENTIFICATION DIVISION. 


ENVIRONMENT DIVISION. 

INPUT-OUTPUT SECTION. 

FILE-CONTROL. 
SELECT filename ASSIGN TO assignment-name 
ORGANIZATION IS org ACCESS MODE IS access 
FILE STATUS IS file-status 


DATA DIVISION. 

FILE SECTION. 

FD filename 

01 recordname 
nn... fieldlength & type 
nn... fieldlength & type 


WORKING-STORAGE SECTION 
01 file-status PICTURE 99. 


PROCEDURE DIVISION. 
OPEN iomode filename 
READ fi lename 
WRITE recordname 
CLOSE filename 
STOP RUN. 

> org indicates the organization, which can be SEQUENTIAL, LINE SEQUENTIAL, 
INDEXED, or RELATIVE. 


> access indicates the access mode, which can be SEQUENTIAL, RANDOM, or 
DYNAMIC. 


> jiomode is for INPUT or OUTPUT mode. If you are only reading from a file, code 
INPUT. If you are only writing to it, code OUTPUT or EXTEND. If you are both 
reading and writing, code I-O, except for organization LINE SEQUENTIAL. 


> Others like filename, recordname, fieldname (nn in the example), fieldlength 
and type are also specified. 
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Targeting COBOL programs for certain environments 
Developing COBOL programs for CICS 


COBOL programs that are written for CICS can run under CICS Transaction Server. 
CICS COBOL application programs that use CICS services must use the CICS 
command-level interface. 


Programming for a DB2 environment 


In general, the coding for your COBOL program will be the same whether or not you 
want it to access a DB2 database. However, to retrieve, update, insert, and delete DB2 
data and use other DB2 services, you must use SQL statements. 


To communicate with DB2, you need to do the following: 
> Code any SQL statements you need, delimiting them with EXEC SQL and 
END-EXEC statements. 


> Use the DB2 precompiler or compile with the SQL compiler option if you are using 
DB2 for OS/390 Version 7 or later. 


Developing COBOL programs for IMS 
With Enterprise COBOL, you can invoke IMS facilities using the following interfaces: 


> CBLTDLI call 
> Language Environment callable service CEETDLI 


You can also run object-oriented COBOL programs in an IMS Java dependent region. 
You can mix the object-oriented COBOL and Java languages in a single application. 


Running COBOL programs under UNIX 

To run COBOL programs in the UNIX environment, you must compile them with the 
Enterprise COBOL or the COBOL for OS/390 and VM compiler. They must be 
reentrant, so use the compiler and linker option RENT. 


Communicating with Java methods 


To achieve inter language interoperability with Java, you need to follow certain rules and 
guidelines for: 


> Using services in the Java Native Interface (JND 
> Coding data types 
> Compiling your COBOL programs 


You can invoke methods that are written in Java from COBOL programs, and you can 
invoke methods that are written in COBOL from Java programs. You need to code 
COBOL object-oriented language for basic Java object capabilities. For additional Java 
capabilities, you can call JNI services. 
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Because Java programs might be multi-threaded and use asynchronous signals, compile 
your COBOL programs with the THREAD option. 


Creating a DLL or a DLL application 


Creating a dynamic link library (DLL) or a DLL application is similar to creating a 
regular COBOL application. It involves writing, compiling, and linking your source 
code. 


Special considerations when writing a DLL or a DLL application include: 
> Determining how the parts of the load module or the application relate to each other 
or to other DLLs 


> Deciding what linking or calling mechanisms to use 


Depending on whether you want a DLL load module or a load module that references a 
separate DLL, you need to use slightly different compiler and linkage editor or binder 
options. 


Structuring OO applications 


You can structure applications that use object-oriented COBOL syntax in one of three 
ways. An OO application can begin with: 


> A COBOL program, which can have any name. 


> A Java class definition that contains a method called main. You can run the 
application with the java command, specifying the name of the class that contains 
main and zero or more strings as command-line arguments. 


> A COBOL class definition that contains a factory method called main. You can run 
the application with the java command, specifying the name of the class that contains 
main and zero or more strings as command-line arguments. 


9.16.6 More information about PL/I language 
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Standards 

The PL/I compiler is designed according to the specifications of the following industry 
standards as understood and interpreted by IBM as of December 1987: 

> American National Standard Code for Information Interchange (ASCII), X3.4 - 1977 


> American National Standard Representation of Pocket Select Characters in 
Information Interchange, level 1, X3.77 - 1980 (proposed to ISO, March 1, 1979) 


> The draft proposed American National Standard Representation of Vertical Carriage 
Positioning Characters in Information Interchange, level 1, d(pANS X3.78 (also 
proposed to ISO, March 1, 1979) 


> Selected features of the American National Standard PL/I General Purpose Subset 
(ANSI X3.74-1987). 
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PL/I program structure 
PL/I is a block-structured language, consisting of packages, procedures, begin blocks, 
statements, expressions, and built-in functions as it is shown in Figure 9-5. 











Load Compilation Level 1 Internal 
Module Unit Procedure Procedure 









Load Compilation Level 1 Begin 
Module Unit Procedure Blocks 



























Figure 9-5 PL/I application structure 


A PL/I application consists of one or more separately loadable entities, known as a load 
module. Each load module can consist of one or more separately compiled entities, 
known as a compilation unit. Unless otherwise stated, a program refers to a PL/I 
application or a compilation unit. 


A compilation unit is a PL/I PACKAGE or an external PROCEDURE. Each package can 
contain zero or more procedures, some or all of which can be exported. A PL/I external 
or internal procedure contains zero or more blocks. 


A PL/I block is either a PROCEDURE or a BEGIN block, any of which contains zero or 
more statements and/or zero or more blocks. 


A procedure is a sequence of statements delimited by a PROCEDURE statement and a 
corresponding END statement, as shown in Example 9-6. A procedure can be a main 
procedure, a subroutine, or a function. An application must have exactly one external 
procedure that has OPTIONS(MAIN). 
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Example 9-6 A PROCEDURE block 


A: procedure; 
statement-1l 
statement-2 


statement=n 
end Name; 


A BEGIN block is a sequence of statements delimited by a BEGIN statement and a 
corresponding END statement, as shown in Example 9-7. 


A program is terminated when the main procedure is terminated. 


Example 9-7 BEGIN block 


B: begin; 
statement-1 
statement-2 


statement-n 
end B; 


PL/I programs are made up of blocks. A block can be either a subroutine, or just a group 
of statements. A PL/I block allows you to produce highly-modular applications, because 
blocks can contain declarations that define variable names and storage class. Thus, you 
can restrict the scope of a variable to a single block or a group of blocks, or you can make 
it known throughout the compilation unit or a load module. 


Input and output 

PL/I input and output statements (such as READ, WRITE, GET, PUT) let you transmit 
data between the main storage and auxiliary storage of a computer. A collection of data 
external to a program is called a data set. Transmission of data from a data set to a 
program is called input. Transmission of data from a program to a data set is called 
output. (If you are using a terminal, “data set” can also mean your terminal.) 


9-30 z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter9 languages.fm 


PL/I input and output statements are concerned with the /ogical organization of a data set 
and not with its physical characteristics. A program can be designed without specific 
knowledge of the input/output devices that are used when the program is executed. To 
allow a source program to deal primarily with the logical aspects of data rather than with 
its physical organization in a data set, PL/I employs models of data sets, called files. A 
file can be associated with different data sets at different times during the execution of a 
program. 


Data transmission 
PL/I uses two types of data transmission: stream and record. 


> In stream-oriented data transmission, the organization of the data in the data set is 
ignored within the program, and the data is treated as though it were a continuous 
stream of individual data values in character form. Data is converted from character 
form to internal form on input, and from internal form to character form on output. 


Stream-oriented data transmission is more versatile than record-oriented data 
transmission in its data-formatting abilities, but is less efficient in terms of run time. 


> In record-oriented data transmission, the data set is a collection of discrete records. 
The record on the external medium is generally an exact copy of the record as it exists 
in internal storage. No data conversion takes place during record-oriented data 
transmission. On input, the data is transmitted exactly as it is recorded in the data set, 
and on output, it is transmitted exactly as it is recorded internally. 


Record-oriented data transmission is more versatile than stream-oriented data 
transmission, in both the manner in which data can be processed and the types of data 
sets that it can process. Since data is recorded in a data set exactly as it appears in 
main storage, any data type is acceptable. No conversions occur, but you must have a 
greater awareness of the data structure. 


Data sets 


In addition to being used as input from and output to your terminal, data sets are stored 
on a variety of auxiliary storage media, including magnetic tape and direct access storage 
devices (DASDs). Despite their variety, these media have characteristics that allow 
common methods of collecting, storing, and transmitting data. The organization of a data 
set determines how data is recorded in a data set and how the data is subsequently 
retrieved so that it can be transmitted to the program. Records are stored in and retrieved 
from a data set either sequentially, on the basis of successive physical or logical 
positions, or directly, by the use of keys specified in data transmission statements. 


PL/I supports the following types of data set organizations: 


> Consecutive. In the consecutive data set organization, records are organized solely on 
the basis of their successive physical positions. When the data set is created, records 
are written consecutively in the order in which they are presented. The records can be 
retrieved only in the order in which they were written. 
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> Indexed. In the indexed data set organization, records are placed in a logical sequence 
based on the key of each record. An indexed data set must reside on a direct-access 
device. A character string key identifies the record and allows direct retrieval, 
replacement, addition, and deletion of records. Sequential processing is also allowed. 


> Relative. In the relative data set organization, numbered records are placed in a 
position relative to each other. The records are numbered in succession, beginning 
with one. A relative data set must reside on a direct-access device. A key that 
specifies the record number identifies the record and allows direct retrieval, 
replacement, addition, and deletion of records. Sequential processing is also allowed. 


> Regional. The regional data set organization is divided into numbered regions, each 
of which can contain one record. The regions are numbered in succession, beginning 
with zero. A region can be accessed by specifying its region number, and perhaps a 
key, in a data transmission statement. The key specifies the region number and 
identifies the region to allow optimized direct retrieval, replacement, addition, and 
deletion of records. 


The data set organizations differ in the way they store data and in the means they use to 
access data. 


For more information on data sets, see Appendix 4, “Working with data sets”. 


Data declarations 


When a PL/I program is executed, it can manipulate many different data items of 
particular data types. Each data item, except an unnamed arithmetic or string constant, is 
referred to in the program by a name. Each data name is given attributes and a meaning 
by a declaration (explicit or implicit). 


A data item is either the value of a variable or a constant. (Note that these terms, as used 
here, are not exactly the same as in general mathematical usage). Data items can be 
single items, called scalars, or they can be a collection of items called data aggregates 
that are groups of data items that can be referred to either collectively or individually. 
The types of data aggregates are arrays, structures, and unions. 


A variable has a value or values that might change during execution of a program. A 
variable is introduced by a declaration, which declares the name and certain attributes of 
the variable. A name is explicitly declared if it appears in a DECLARE statement that 
explicitly declares attributes of names. 


A constant has a value that cannot change. Constants for computational data are referred 
to by stating the value of the constant or naming the constant ina DECLARE statement. 


Preprocessors 


The PL/I compiler allows you to select one or more of the integrated preprocessors as 
required for use in your program. You can select the include preprocessor, the macro 
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preprocessor, the SQL preprocessor, or the CICS preprocessor—and you can select the 
order in which you would like them to be called. 


Each preprocessor supports a number of options to allow you to tailor the processing to 
your needs. 


> Include preprocessor. This allows you to incorporate external source files into your 
programs by using include directives other than the PL/I directive % INCLUDE (the 
%INCLUDE directive is used to incorporate external text into the source program). 


> Macro preprocessor. Macros allow you to write commonly used PL/I code in a way 
that hides implementation details and the data that is manipulated, and exposes only 
the operations. In contrast with a generalized subroutine, macros allow generation of 
only the code that is needed for each individual use. 

> SQL preprocessor. In general, the coding for your PL/I program will be the same 
whether or not you want it to access a DB2 database. However, to retrieve, update, 
insert, and delete DB2 data and use other DB2 services, you must use SQL 
statements. You can use dynamic and static EXEC SQL statements in PL/I 
applications. 


To communicate with DB2, you need to do the following: 
— Code any SQL statements you need, delimiting them with EXEC SQL. 


— Use the DB2 precompiler or, if using DB2 for OS/390 Version 7 Release | or later 
compile with the PL/I PP(SQL()) compiler option. 


Before you can take advantage of EXEC SQL support, you must have authority to 
access a DB2 system. 


Note: The PL/I SQL Preprocessor currently does not support DBCS. 


> CICS preprocessor. You can use EXEC CICS statements in PL/I applications that run 
as transactions under CICS. 


Interfaces to other products 
Using the Sort program 


The compiler provides an interface called PLISRTx (x = A, B, C, or D) that allows you to 
make use of the IBM-supplied Sort programs. 


When used from PL/I, the Sort program sorts records of all normal lengths on a large 
number of sorting fields. Data of most types can be sorted into ascending or descending 
order. The source of the data to be sorted can be either a data set or a user-written PL/I 
procedure that the Sort program will call each time a record is required for the sort. 
Similarly, the destination of the sort can be a data set or a PL/I procedure that handles the 
sorted records. 
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ILC with C 


Inter-Language Communication (ILC) between PL/I and C allows you to use many of the 
data types common to both languages and should enable you to write PL/I code that 
either calls or is called by C. 


Interfacing with Java 


The following is a brief description of the Java Native Interface (JNI), and it explains 
why you might be interested in using it with PL/I. Instructions on how to build and run 
the Java - PL/I sample applications assume the work is being done in the UNIX System 
Services (USS) environment of S/390. 


Before you can communicate with Java from PL/I, you need to have Java installed on 
your S/390 system. 


The Java Native Interface (JNI) 


Java is an object-oriented programming language invented by Sun Microsystems Inc., 
and it provides a powerful way to make Internet documents interactive. 


The Java Native Interface (JNI) is the Java interface to native programming languages 
and is part of the Java Development Kits. By writing programs that use the JNI, you 
ensure that your code is portable across many platforms. 


The JNI allows Java code that runs within a Java Virtual Machine (JVM) to operate with 
applications and libraries written in other languages, such as PL/I. In addition, the 
Invocation API allows you to embed a Java Virtual Machine into your native PL/I 
applications. 


Java is a fairly complete programming language; however, there are situations in which 
you want to call a program written in another programming language. You would do this 
from Java with a method call to a native language, known as a native method. 


Programming through the JNI lets you use native methods to do many different 
operations. A native method can: 


> Utilize Java objects in the same way that a Java method uses these objects 


> Create Java objects, including arrays and strings, and then inspect and use these 
objects to perform its tasks 


> Inspect and use objects created by Java application code 


> Update Java objects that it created or were passed to it; these updated objects can then 
be made available to the Java application 


Finally, native methods can also easily call already-existing Java methods, capitalizing 
on the functionality already incorporated in the Java programming framework. In these 
ways, both the native language side and the Java side of an application can create, update, 
and access Java objects, and then share these objects between them. 
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Using the SAX parser 


The compiler provides an interface called PLISAXx (x = A or B) that provides you with 
basic XML capability to PL/I. The support includes a high-speed XML parser, which 
allows programs to consume inbound XML messages, check them for being 
well-formed, and transform their contents to PL/I data structures. 


The XML support does not provide XML generation, which must instead be 
accomplished by PL/I program logic. The XML support has no special environmental 
requirements. It executes in all the principal run-time environments, including CICS, 
IMS, and MQ Series, as well as z/OS and OS/390 batch and TSO. 


Using the Checkpoint/Restart facility 


The PL/I Checkpoint/Restart feature provides a convenient method of taking checkpoints 
during the execution of a long-running program in a batch environment. 


PL/I Checkpoint/Restart uses the Advanced Checkpoint/Restart Facility of the operating 
system. 


Using user exits 


PL/I provides a number of user exits that allow you to customize the PL/I product to suit 
your needs. The PL/I products supply default exits and the associated source files. 


With PL/I, you can write your own user exit or use the exit provided with the product, 
either “as is” or modified, depending on what you want to do with it. 


9.16.7 More information about the C++ language 


According to ISO/IEC 14882:2003, C++ is a general-purpose programming language 
based on the C programming language as described in ISO/IEC 9899:1990. In addition to 
the facilities provided by C, C++ provides additional data types, classes, templates, 
exceptions, namespaces, inline functions, operator overloading, function-name 
overloading, references, free-store management operators, and additional library 
facilities. 


Important: According to Dr. Bjarne Stroustrup, the designer of C++, C++ is a direct 
descendant of C that retains almost all of C as a subset. C++ provides stronger type 
checking than C, and it directly supports a wider range of programming styles than C. 
C++ supports data abstraction, object-oriented programming, and _ generic 
programming. (Source: http://www.research.att.com/~bs/bs_faq.html#free) 


In the following paragraphs we refer to the C and C++ languages simply by referring to 
C. 
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The C library contains functions for input and output, mathematics, exception handling, 
string and character manipulation, dynamic memory management, as well as date and 
time manipulation. Use of this library helps to maintain program portability, because the 
underlying implementation details for the various operations need not concern the 
programmer. 


C supports numerous data types, including characters, integers, floating-point numbers 
and pointers—each in a variety of forms. In addition, C supports arrays, structures 
(records), unions, and enumerations. 


Source programs 


A C source program is a collection of one or more directives, declarations, and 
statements contained in one or more source files. 


> Directives instruct the C preprocessor to act on the text of the program. 


> Declarations establish names and define characteristics such as scope, data type and 
linkage. 


> Statements specify the action to be performed. 


> Definitions are declarations that allocate storage for data objects or define a body for 
functions. An object definition allocates storage and may optionally initialize the 
object. 


A function definition precedes the function body. The function body is a compound 
statement that can contain declarations and statements that define what the function does. 
The function definition declares the function name, its parameters, and the data type of 
the value it returns. 


The order and scope of declarations affect how you can use variables and functions in 
statements. In particular, an identifier can be used only after it is declared. 


A program must contain at least one function definition. If the program contains only one 
function definition, the function must be called main. If the program contains more than 
one function definition, only one of the functions can be called main. The main function 
is the first function called when a program is run. 


C source files 


A C source file is the collection of text files that contains all of a C source program. It can 
include any of the functions that the program needs. To create an executable object 
module, you compile the source files individually and then link them as one program. 
With the #include directive, you can combine source files into larger source files. 


A source file contains any combination of directives, declarations, and definitions. You 
can split items such as function definitions and large data structures between text files, 
but you cannot split them between compiled files. Before the source file is compiled, the 
preprocessor filters out preprocessor directives that may change the files. As a result of 
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the preprocessing stage, preprocessor directives are completed, macros are expanded, 
and a source file is created containing C statements, completed directives, declarations, 
and definitions. 


It is sometimes useful to place variable definitions in one source file and declare 
references to those variables in any source files that use them. This procedure makes 
definitions easy to find and change, if necessary. You can also organize constants and 
macros into separate files and include them into source files as required. 


Directives in a source file apply to that source file and its included files only. Each 
directive applies only to the part of the file following the directive. 


Data types 
The C data types are: 


Characters 
Floating-Point Numbers 
Integers 

Enumerations 
Structures 

Unions 


vvvvvy 


From these types, you can derive the following: 


> Arrays 
> Pointers 
> Functions 


The void type 

The void is data type always represents an empty set of values. The keyword for this type 
is void. When a function does not return a value, you should use void as the type specifier 
in the function definition and declaration. The only object that can be declared with the 
type specifier void is a pointer. 


9.16.8 More information about the Java language 


Programming languages like Enterprise COBOL and Enterprise PL/I in z/OS provide 
interfaces to programs written in Java Language. These languages provide a set of 
interfaces or facilities to have an interaction with programs written in Java, as explained 
for COBOL in “Communicating with Java methods” on page 9-27 and for PL/I in 
“Interfacing with Java” on page 9-34. 


IBM SDK for z/OS 


The IBM SDK for z/OS, Java 2 Technology Edition, Version 1.4 product is IBM's port of 
the Sun Microsystems Java Software Development Kit (SDK) to the z/OS zSeries 
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platform. The IBM SDK for z/OS, Java 2 Technology Edition, Version 1.4 product at the 
SDK 1.4 level is certified as a fully compliant Java product. IBM has successfully 
executed the Java Certification Kit (JCK) 1.4 provided by Sun Microsystems, Inc. 


IBM SDK for z/OS, Java 2 Technology Edition, Version 1.4 is operational within the 
z/OS Version 1 Release 4 operating system or later, or z/OS.e Version | Release 4 
operating system or later. It provides a Java execution environment equivalent to that 
available on any other server platform. 


WebSphere Application Server 

WebSphere Application Server is a comprehensive, sophisticated, Java 2 Enterprise 
Edition (J2EE) and Web services technology-based application platform, specifically 
designed to provide an interface to the z/OS operating system. V5.1 includes 
maintenance release V5.0.2 support for the Software Development Kit for Java 
Technology Edition 1.4 (SDK 1.4) client container and improvements in Web services 
interoperability and security, and systems management. 


For more details refer to Appendix 15, “HTTP Server and WebSphere Application Server 
on z/OS”. 


For more information, refer to the following manual: 
> IBM SDK for z/OS V1.4 Program Directory, G111-2822 
You can find it at the following Web site: 
http://publibz. boulder. ibm.com/cgi-bin/bookmgr_0S390/Shelves/EZ2JV201 


> For information about WebSphere Application Server, see Appendix 15, “HTTP 
Server and WebSphere Application Server on z/OS”. 


9.16.9 More information about the CLIST language 
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Besides issuing TSO/E commands, CLISTs can perform more complex programming 
tasks. The CLIST language includes the programming tools you need to write extensive, 
structured applications. CLISTs can perform any number of complex tasks, from 
displaying a series of full-screen panels to managing programs written in other 
languages. 


Features of the CLIST language 
The CLIST language provides a wide range of programming functions. Its features 
include: 


> An extensive set of arithmetic and logical operators for processing numeric data 

> String-handling functions for processing character data 

> CLIST statements that let you structure your programs, perform I/O, define and 
modify variables, and handle errors and attention interrupts 
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Categories of CLISTs 
A CLIST can perform a wide range of tasks. Three general categories of CLISTs are: 


> CLISTs that perform routine tasks 
> CLISTs that are structured applications 
> CLISTs that manage applications written in other languages 


CLISTs that perform routine tasks 


As a user of TSO/E, you will probably perform certain tasks on a regular basis. These 
tasks may involve entering TSO/E commands to check on the status of data sets, to 
allocate data sets for particular programs, and to print files. 


You can write CLISTs that significantly reduce the amount of time that you have to spend 
on these routine tasks. By grouping together in a CLIST the instructions required to 
complete a task, you reduce the time, number of keystrokes, and errors involved in 
performing the task; thus, you increase your productivity. Such a CLIST can consist of 
TSO/E commands only, or a combination of TSO/E commands, JCL statements, or 
CLIST statements. 


CLISTs that are structured applications 


The CLIST language includes the basic tools you need to write complete, structured 
applications. Any CLIST can invoke another CLIST, which is referred to as a nested 
CLIST. CLISTs can also contain separate routines called sub-procedures. Nested CLISTs 
and sub-procedures let you separate your CLISTs into logical units and put common 
functions in a single location. Specific CLIST statements let you: 


> Define common data for sub-procedures and nested CLISTs 
> Restrict data to certain sub-procedures and CLISTs 
> Pass specific data to a sub-procedure or nested CLIST 


For interactive applications, CLISTs can issue commands of the Interactive System 
Productivity Facility (ISPF) to display full-screen panels. Conversely, ISPF panels can 
invoke CLISTs, based on input that a user types on the panel. 


CLISTs that manage applications written in other languages 


You might have access to applications that are written in other programming languages. 
However, the interfaces to these applications might not be easy to use or remember. 
Rather than write new applications, you can write CLISTs that provide easy-to-use 
interfaces between the user and such applications. 


A CLIST can send messages to, and receive messages from, the terminal to determine 
what the user wants to do. Then, based on this information, the CLIST can set up the 
environment and issue the commands required to invoke the program that performs the 
requested tasks. 


Chapter 9. Using programming languages on z/OS 9-39 


Chapter9 languages.fm Draft Document for Review December 3, 2004 3:15 pm 


Executing CLISTs 

To execute a CLIST, use the EXEC command. From an ISPF command line, type TSO in 
front of the command. In TSO/E EDIT or TEST mode, use the EXEC subcommand as 
you would use the EXEC command. (CLISTs executed under EDIT or TEST can issue 
only EDIT or TEST sub-commands and CLIST statements, but you can use the END 
sub-command in a CLIST to end EDIT or TEST mode and allow the CLIST to issue 
TSO/E commands.) 


9.16.10 More information about the REXX language 
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The System Product Interpreter (SPI), a component of the z/VM operating system 
processes procedures, XEDIT macros, and programs written in the REXX language. The 
REXX interpreter operates directly on the program as it executes, line-by-line and 
word-by-word. 


The structure of a REXX program is simple. It provides a conventional selection of 
control constructs. For example, these include IF... THEN... ELSE... for simple 
conditional processing, SELECT... WHEN... OTHERWISE... END for selecting from a 
number of alternatives, and several varieties of DO... END for grouping and repetitions. 
No GOTO instruction is included, but a SIGNAL instruction is provided for abnormal 
transfer of control such as error exits and computed branching. 


There is no mechanism for declaring variables. Variables may be documented and 
initialized at the start of a program and implicit declarations occur during execution. The 
only true declarations are the markers (labels) that identify points in the program that 
may be used as the targets of SIGNAL instructions or internal routine calls. 


Input and output functions in REXX are defined only for simple character-based 
operations. 


Instructions written in any high level language, such as REXX, must be prepared for 

execution. The two types of programs that can perform this task are: 

> An interpreter, which parses and executes an instruction before it parses and executes 
the next instruction. 

> Accompiler, which translates all the instructions of a program into a machine code 
program. It can keep the machine code program for later execution. It does not 
execute the program. 


The input to a compiler is the source program that you write. The output from a compiler 
is the compiled program and the listing. The process of translating a source program into 
a compiled program is known as compilation. 


For a more complete reference to REXX’s potential, see this Web site: 


http: //www-306.ibm.com/software/awdtools/REXX/1anguage/REXX1inks.html 
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A REXX program compiled under z/OS can run under z/VM. Similarly, a REXX 
program compiled under z/VM can run under z/OS. A REXX program compiled under 
z/OS or z/VM can run under VSE/ESA if REXX/VSE is installed. 


Compiling and executing REXX command lists 
There are three main components of the REXX language when using a compiler: 


> 


IBM Compiler for REXX on zSeries. The Compiler translates REXX source 
programs into compiled programs. 


IBM Library for REXX on zSeries. The Library contains routines that are called by 
compiled programs at runtime. 


Alternate Library. The Alternate Library contains a language processor that 
transforms the compiled programs and runs them with the interpreter. It can be used 
by z/OS and z/VM users who do not have the IBM Library for REXX on zSeries to 
run compiled programs. 


The Compiler and Library run on z/OS systems with TSO/E, and under CMS on 
VM/XA, VM/ESA, and z/VM systems. The IBM Library for REXX in REXX/VSE runs 
under VSE/ESA. 


The Compiler can produce output in the following forms: 


> 


Compiled EXECs. These behave exactly like interpreted REXX programs. They are 
invoked the same way by the system's EXEC handler, and the search sequence is the 
same. The easiest way of replacing interpreted programs with compiled programs is 
by producing compiled EXECs. Users need not know whether the REXX programs 
they use are compiled EXECs or interpretable programs. Compiled EXECs can be 
sent to VSE/ESA to be run there. 


Object modules under z/OS or TEXT files under z/VM (a TEXT file is an object-code 
file whose external references have not been resolved. This term is used on z/VM 
only). These must be transformed into executable form (load modules) before they 
can be used. Load modules and MODULE files are invoked the same way as load 
modules derived from other compilers, and the same search sequence applies. 
However, the search sequence is different from that of interpreted REXX programs 
and compiled EXECs. These load modules can be used as commands and as parts of 
REXX function packages. Object modules or MODULE files can be sent to 
VSE/ESA to build phases. 


IEXEC output. This output contains the expanded source of the REXX program 
being compiled. Expanded means that the main program and all the parts included at 
compilation time by means of the % INCLUDE directive are contained in the IEXEC 
output. Only the text within the specified margins is contained in the IEXEC output. 
Note, however, that the default setting of MARGINS includes the entire text in the 
input records. 
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9.16.11 More information about the z/OS Language Environment 


Figure 9-6 shows a common run-time environment established through Language 
Environment. 
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Figure 9-6 Language Environment's common runtime environment 











The language-specific portions of Language Environment provide language interfaces 
and specific services that are supported for each individual language, and that can be 
called through a common callable interface. In the following section we discuss some of 
these interfaces and services in more detail. 


The Language Environment architecture is built from models. These are models for: 


Program management 
Condition handling 
Message services 
Storage management 


vvvy 
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Program management model 


The Language Environment program management model provides a framework within 
which an application runs. It is the foundation of all of the component models (condition 
handling, run-time message handling, and storage management) that comprise the 
Language Environment architecture. 


The program management model defines the effects of programming language semantics 
in mixed-language applications, and integrates transaction processing and 
multithreading. 


Some terms used to describe the program management model are common programming 
terms; other terms are described differently in other languages. It is important that you 
understand the meaning of the terminology in a Language Environment context as 
compared to other contexts. 


Program management 


Program management defines the program execution constructs of an application, and 
the semantics associated with the integration of various components management of such 
constructs. 


Three entities, process, enclave, and thread, are at the core of the Language Environment 
program management model. 


Processes 


The highest level component of the Language Environment program model is the 
process. A process consists of at least one enclave and is logically separate from other 
processes. Language Environment generally does not allow language file sharing across 
enclaves nor does it provide the ability to access collections of externally stored data. 


Enclaves 


A key feature of the program management model is the enclave, a collection of the 
routines that make up an application. The enclave is the equivalent of any of the 
following: 


Arun unit, in COBOL 

A program, consisting of a main C function and its sub-functions, in C and C++ 
A main procedure and all of its subroutines, in PL/I 

A program and its subroutines, in Fortran 


vvvy 


In Language Environment, environment is normally a reference to the run-time 
environment of HLLs at the enclave level. The enclave consists of one main routine and 
zero or more subroutines. The main routine is the first to execute in an enclave; all 
subsequent routines are named as subroutines. 
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Threads 


Each enclave consists of at least one thread, the basic instance of a particular routine. A 
thread is created during enclave initialization with its own run-time stack, which keeps 
track of the thread's execution, as well as a unique instruction counter, registers, and 
condition-handling mechanisms. Each thread represents an independent instance of a 
routine running under an enclave's resources. 





Process 


Enclave Enclave 


External External External External 
data X data Y data Y data Z 





Process 


Thread 





External External 
data X data Y 


Figure 9-7 Full Language Environment program model 














Figure 9-7 illustrates the full Language Environment program model, with its multiple 
processes, enclaves, and threads. As the figure shows, each process is within its own 
address space. An enclave consists of one main routine, with any number of subroutines. 
A main routine might not be active at all times in a POSIX application, if the thread in 
which the main routine executes terminates before the other threads it created. 


The threads can create enclaves, which can create more threads, and so on. 
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Condition-handling model 

For single-language and mixed-language applications, the Language Environment 
run-time library provides a consistent and predictable condition-handling facility. It does 
not replace current HLL condition handling, but instead allows each language to respond 
to its own unique environment as well as to a mixed-language environment. 


Language Environment condition management gives you the flexibility to respond 
directly to conditions by providing callable services to signal conditions and to 
interrogate information about those conditions. It also provides functions for error 
diagnosis, reporting, and recovery. 


Message-handling model and national language support 
A set of common message handling services that create and send run-time informational 
and diagnostic messages is provided by Language Environment. 


With the message handling services, you can use the condition token that is returned from 
a callable service or from some other signaled condition, format it into a message, and 
deliver it to a defined output device or to a buffer. 


National language support callable services allow you to set a national language that 
affects the language of the error messages and the names of the day, week, and month. It 
also allows you to change the country setting, which affects the default date format, time 
format, currency symbol, decimal separator character, and thousands separator. 


Storage management model 

Common storage management services are provided for all Language 
Environment-conforming programming languages; Language Environment controls 
stack and heap storage used at run time. It allows single-language and mixed-language 
applications to access a central set of storage management facilities, and offers a 
multiple-heap storage model to languages that do not now provide one. The common 
storage model removes the need for each language to maintain a unique storage manager, 
and avoids the incompatibilities between different storage mechanisms. 


Running your program with Language Environment 
After compiling your program you can do the following: 


> Link-edit and run an existing object module and accept the default Language 
Environment run-time options 


> Link-edit and run an existing object module and specify new Language Environment 
run-time options 


> Call a Language Environment service 
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Accepting the default run-time options 


To run an existing object module under batch and accept all of the default Language 
Environment run-time options, you can use a Language Environment-provided link-edit 
and run cataloged procedure CEEWLG The CEEWLG procedure identifies the 
Language Environment libraries that your object module needs to link-edit and run. 


Run-time library services 


The Language Environment libraries are located in data sets identified with a high-level 
qualifier specific to the installation. For example SCEERUN contains the run-time 
library routines needed during execution of applications written in C/C++, PL/I, COBOL 
and FORTRAN. SCEERUN2 contains the run-time library routines needed during 
execution of applications written in C/C++ and COBOL. 


Applications that require the run-time library provided by Language Environment can 
access the SCEERUN and SCEERUN2 data sets using one or any combination of these 
methods: 


> LNKLST 
> STEPLIB 
> RTLS 


Important: Language Environment library routines are divided into two categories: 
resident routines and dynamic routines. The resident routines are linked with the 
application and include such things as initialization/termination routines and pointers 
to callable services. The dynamic routines are not part of the application and are 
dynamically loaded during run time. 


There are certain considerations that you must be aware of before link-editing and 
running applications under Language Environment. 


Language Environment Callable Services 

There is a common set of callable services designed to supplement the programmer’s 
language intrinsic capability. For example, COBOL application developers will find 
Language Environment's consistent condition handling services especially useful. For all 
languages the same occurs with common math services, as well as the date and time 
services. 


Language Environment callable services are divided into the following groups: 


Communicating Conditions Services 
Condition Handling Services 

Date and Time Services 

Dynamic Storage Services 

General Callable Services 
Initialization/Termination Services 


vvvvvy 
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Locale Callable Services 

Math Services 

Message Handling Services 
National Language Support Services 


vvvy 


For a complete description of the callable services, see z/OS Language Environment 
Programming Reference, SA22-7562. 


Language Environment calling conventions 

Language Environment services can be invoked by HLL library routines, other Language 
Environment services, and user-written HLL calls. In many cases, services will be 
invoked by HLL library routines as a result of a user-specified function, such as a 
COBOL intrinsic function. Following are examples of the invocation of a callable math 
service from three of the languages we have described in this chapter. Also look at the 
referenced examples in 9.16.9, “More information about the CLIST language” on 
page 9-38. 


Invoking Callable Services from COBOL 


Example 9-8 shows how a COBOL program invokes the math callable services 
CEESDLGI1 for log base 10. 


Example 9-8 Sample invocation of a math callable service from a COBOL program 


EF ARGIRL COMP-2. 

Ta FBCODE PIC X(12). 

77 RESLTRL COMP-2. 
CALL "CEESDLG1" USING ARG1IRL , FBCODE , 
RESLTRL. 
































Invoking Callable Services from PL/ 


Example 9-9 shows a PL/I program invoking the math callable services CEESIMOD and 
CEESSLOG for Modular arithmetic and log base e. 


Example 9-9 Sample invocation of a math callable services from a PL/I program 


PLIMATH: PROC OPTIONS (MAIN) ; 
DCL CEESSLOG ENTRY OPTIONS (ASM) EXTERNAL; 
DCL CEESIMOD ENTRY OPTIONS (ASM) EXTERNAL; 
DCL ARG1 RESULT REAL FLOAT DEC (6); 
DCL ARGM1 ARGM2 RES2 FLOAT BINARY (21) 













































































DCL FC CHARACTER (12); 
/* Call log base e routine, which has mf 
/* only one input parameter #/ 





CALL CEESSLOG (ARG1, FC, RESULT) 
IF ( FC = '000000000000000000000000'X ) 
THEN DO; 
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PUT SKIP LIST 
( "Error occurred in call to CEESSLOG.' ); 
SE; 
/* Call modular arithmetic routine, ae 
/* which has two input parameters aS 











CALL CEESIMOD (ARGM1, ARGM2, FC, RES2); 

IF ( FC = '000000000000000000000000'X ) 

THEN DO; 

PUT SKIP LIST 

{ *Brror occurred in call to CEESIMOD.' ); 















































Invoking Callable Services from C 


Example 9-10 shows a C program invoking the math callable services CEESDGL1 and 
CEESIMOD for Log base 10 and modular arithmetic. 


Example 9-10 Sample invocation of a math callable services from a C program 


#include <leawi.h> 
#include <string.h> 
#include <stdio.h> 
int main (void) { 
_FLOAT8 fl,result; 
_INTA intl, Tit2, aitry 
_FEEDBACK fc; 
#define SUCCESS "\0\0\0\0" 
fl = 1000.0; 
CEESDLG1(&f1,&fc, &result) ; 
if (memcmp(&fc,SUCCESS,4) != 0) { 
printf("CEESDLG1 failed with message number %d\n", 
fc.tok_msgno) ; 


exit (2999); 
} 
printf("%f log base 10 is %f\n",fl,result); 
intl = 39; 
inte = 7s 


CEESIMOD(&int1, &int2, &fc, &intr) ; 
if (memcmp(&fc,SUCCESS,4) != 0) { 
printf ("CEESIMOD failed with message number %d\n", 
fc.tok_msgno) ; 
exit (2999); 
} 


printf("%d modulo %d is %d\n",intl,int2, intr); 
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Invoking Callable Services from Assembler 


Example 9-11 shows the invocation of a callable service from an assembler program. 


Example 9-11 Sample invocation of a Callable Service from an assembler program 


PLIST 


DC 
PARM1 


FC 
CEE000 


LA R1,PLIST 

L R15,=V(CEESERV) 

BALR R14,R15 

CLC FC(12),CEEOQOO Check if feedback code is zero 
BNE ERI If not, branch to error routine 


DS OD 
DC A(PARM1) 


Parms 2 through n 
A(FC+X '80000000' ) Feedback code as last parm 
DC OF *S* Parm 1 


Parms 2 through n 
DS 12C Feedback code as last parm 
DE 12X'00' Good feedback code 
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10 


Compiling and link-editing a 
program on z/OS 








Objective: A z/OS application developer needs to know how to compile, link, 
and execute a program. 


In this chapter, you will learn: 


> How to compile a source program 
> How to link-edit object modules to create a load module 
> How to execute a load module 




















10.1 Source, object, and load modules 


A program can be divided into logical units that perform specific functions. A logical 
unit of code that performs a function or several related functions is a module. Separate 
functions should be programmed into separate modules, a process called modular 
programming. Each module can be written in the symbolic language that best suits the 
function to be performed. 


Each module is assembled or compiled by one of the language translators. The input to a 
language translator is a source module; the output from a language translator is an object 
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module. Before an object module can be executed, it must be processed by the linkage 
editor. The output of the linkage editor is a load module; see Figure 10-1. 















Pre-compiler, 
language 
translator 





Load 
module 


Object Linkage 
module editor 















Figure 10-1 Source, object, and load modules 


Depending on the status of the module, whatever it is—source, object or load—it can be 
stored in a library. A library is a partitioned data set (PDS) or a partitioned data set 
extended (PDSE) on direct access storage. PDSs and PDSEs are divided into partitions 
called members. In a library, each member contains a program or part of a program. 


10.2 Source libraries 


10-2 


A source program is a set of statements written in any computer language, as described in 
Chapter 9, “Using programming languages on z/OS”. Source programs, once they are 
error-free, are stored in a partitioned data set known as a source library. Source libraries 
contain the source code to be submitted for a compilation process, or to be retrieved for 
modification by an application programmer. 


A copybook is a source library containing prewritten text. It is used to copy text into a 
source program, at compile time, as a shortcut to avoid having to code the same set of 
statements over and over again. It is usually a shared library where programmers can 
store commonly-used program segments to be later included into their source programs. 
It should not be confused with a subroutine or a program. A copybook member is just 
text; it might not be actual programming language statements. 


A subroutine is a commonly-called routine that performs a predefined function. The 
purpose behind a copybook member and a subroutine are essentially the same, to avoid 
having to code something that has previously been done. However, a subroutine is a 
small program (compiled, link-edited and executable) that is called and returns a result, 
based on the information that it was passed. A copybook member is just text that will be 
included in a source program on its way to becoming an executable program. The term 
copybook is a COBOL term, but the same concept is used in most programming 
languages. 


If you use copybooks in the program that you are compiling, you can retrieve them from 
the source library by supplying a DD statement for SYSLIB or other libraries that you 
specify in COPY statements. In Example 10-1 on page 10-3, we insert the text in member 
INPUTRCD from the library DEPT88.BOBS.COBLIB into the source program that is to 
be compiled. 
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Example 10-1 Copybook in COBOL source code 


//COBOL.SYSLIB DD DISP=SHR, DSN=DEPT88.BOBS.COBLIB 
//SYSIN DD * 
IDENTIFICATION DIVISION. 








COPY INPUTRCD 


Libraries must reside on direct access storage devices (DASDs). They cannot be in a 
hierarchical file system (HFS) when you compile using JCL or under TSO. 


10.3 Compiling programs on z/OS 


The function of a compiler is to translate source code into object code. The object code 
must then be processed by a linkage editor, a binder or a loader before it is executed. 
During the compilation of a source module, the compiler assigns relative addresses to all 
instructions, data elements, and labels, starting from zero. The addresses are in the form 
of a base address plus a displacement. This allows programs to be relocated, that is, they 
do not have to be loaded into the same location in storage each time that they are 
executed. See 10.4, “Creating load modules for executable programs” on page 10-19 for 
more information on relocatable programs. Any references to external programs or 
subroutines are left as unresolved. These references will either be resolved when the 
object module is linked, or dynamically resolved when the program is executed. 


To compile programs on z/OS, you can use a batch job, or you can compile under TSO/E 
through commands, CLISTs, or ISPF panels. Also, for COBOL programs, you can 
compile programs in a z/OS UNIX shell by using the cob2 command. 


For compiling through a batch job, z/OS includes a set of cataloged procedures that can 
help you avoid some of the JCL coding you would otherwise need to do. If none of the 
cataloged procedures meet your needs, you will need to write all of the JCL for the 
compilation. 


As part of the compilation step, you need to define the data sets needed for the 
compilation and specify any compiler options necessary for your program and the desired 
output. 


The data set (library) that contains your source code is specified on the SYSIN DD 
statement, as shown in Example 10-2. 


Example 10-2 SYSIN DD statement for the source code 





//SYSIN DD DSNAME=dsname, 
// DISP=SHR 
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You can place your source code directly in the input stream. If you do so, use this SYSIN 
DD statement: 


//SYSIN DD * 
When you use the DD * convention, the source code must follow the statement. If 


another job step follows the compilation, the EXEC statement for that step follows the /* 
statement or the last source statement. 


10.3.1 Pre-compiler 


Some compilers have a precompile or preprocessor to process statements that are not part 
of the computer programming language. If your source program contains EXEC CICS 
statements or EXEC SQL statements, then it must first be pre-processed to convert these 
statements into COBOL, PL/I or Assembler language statements, depending on the 
language in which your program is written. 


10.3.2 Compiling with cataloged procedures 
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The simplest way to compile your program under z/OS is by using a batch job with a 
cataloged procedure. A cataloged procedure is a set of job control statements placed in a 
partitioned data set (PDS) called the procedure library (PROCLIB). z/OS comes with a 
procedure library called SYS1.PROCLIB. This system library is discussed more 
thoroughly in 17.5, “SYS1.PROCLIB” on page 17-22. A simple way to look at the use of 
cataloged procedures is to think of them as copybooks. Instead of source statements, 
however, cataloged procedures contain JCL statements. You do not need to code a JCL 
statement to tell the system where to find them because they are located in a system 
library which automatically gets searched when you execute JCL that references a 
procedure. 


You need to include the following information in the JCL for compilation: 


— Job description 
— Execution statement to invoke the compiler 
— Definitions for the data sets needed but not supplied by the procedure 


COBOL compile procedure 

The JCL in Example 10-3 executes the IGYWC procedure, which is a single-step 
procedure for compiling a source program. It produces an object module that will be 
stored in the SYSLIN data set, as we can see in Example 10-4. 
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Example 10-3 Basic JCL for compiling a COBOL source program inline 


//COMP JOB 
//COMPILE EXEC IGYWC 
//SYSIN DD * 


IDENTIFICATION DIVISION (source program) 


/* 
// 


The SYSIN DD statement indicates the location of the source program. In this case, the 
asterisk (*) indicates that it is in the same input stream. 


For PL/I programs, in addition to the replacement of the source program, the compile 
EXEC statement should be replaced by: 

//compile EXEC IBMZC 
The statements shown in Example 10-4 make up the IGYWC cataloged procedure used 


in Example 10-3. As mentioned previously, the result of the compilation process, the 
compiled program, is placed in the data set identified on the SYSLIN DD statement. 


Example 10-4 Procedure IGYWC - COBOL compile 


//IGYWC PROC LNGPRFX='IGY.V3R2M0',SYSLBLK=3200 











/1* 
//* COMPILE A COBOL PROGRAM 
//* 
//* PARAMETER DEFAULT VALUE 




















//* SYSLBLK 3200 
//* LNGPRFX IGY.V3R2M0 



















































































//* 

//* CALLER MUST SUPPLY //COBOL.SYSIN DD 
//* 

//COBOL EXEC PGM=IGYCRCTL, REGION=2048K 
//STEPLIB DD DSNAME=&LNGPRFX..SIGYCOMP, 
// DISP=SHR 

//SYSPRINT DD SYSOUT=* 

//SYSLIN DD DSNAME=&&LOADSET, UNIT=SYSDA, 
// DISP= (MOD, PASS) , SPACE=(TRK, (3,3)), 
// DCB= (BLKSIZE=&SYSLBLK) 
//SYSUT1 DD UNIT=SYSDA, SPACE=(CYL, (1,1)) 
//SYSUT2 DD UNIT=SYSDA, SPACE=(CYL, (1,1)) 
//SYSUT3 DD UNIT=SYSDA, SPACE=(CYL, (1,1)) 
//SYSUT4 DD UNIT=SYSDA, SPACE=(CYL, (1,1)) 
//SYSUT5 DD UNIT=SYSDA, SPACE=(CYL, (1,1)) 
//SYSUT6 DD UNIT=SYSDA, SPACE=(CYL, (1,1)) 
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//SYSUT7 DD UNIT=SYSDA, SPACE= (CYL, (1,1)) 





COBOL pre-processor and compile and link procedure 

The JCL in Example 10-5 executes the DFHEITVL procedure, which is a three-step 
procedure for pre-processing a COBOL source program, compiling the output from the 
pre-processing step, and then linking it into a load library. The first step produces 
pre-processed source code in the SYSPUNCH temporary data sets, with any CICS calls 
expanded into COBOL language statements. The second step takes this temporary data 
set as input and produces an object module that is stored in the SYSLIN temporary data 
set, as shown in Example 10-6 on page 10-7. The third step takes the SYSLIN temporary 
data set as input, as well as any other modules that might need to be included, and creates 
a load module in the data set referenced by the SYSLMOD DD statement. 


In Example 10-5, you can see that the JCL is a bit more complicated than in the simple 
compile job (Example 10-3 on page 10-5). Once we go from one step to multiple steps, 
we must tell the system which step we are referring to when we supply JCL overrides. 


Looking at the JCL in Example 10-6 on page 10-7, we see that the first step (each step is 
an EXEC statement, and the step name is the name on the same line as the EXEC 
statement) is named TRN, so we must qualify the SYSIN DD statement with TRN to 
ensure that it will be used in the TRN step. 


Similarly, the fourth step is called LKED, so we must qualify the SYSIN DD statement 
with LKED in order for it to apply to the LKED step. See 5.10.1, “JCL PROC statement 
override” on page 5-15 for more information on overriding a cataloged procedure. 


The end result of running the JCL in Example 10-5 (assuming that there are no errors) 
should be to pre-process and compile our inline source program, link-edit the object 
code, and then store the load module called PROGI in the data set MY. LOADLIB. 


Example 10-5 Basic JCL for pre-processing, compiling, and linking a COBOL source 
program inline 


/ /PPCOMLNK JOB 
































//PPCL EXEC DFHEITVL, PROGLIB=’ MY .LOADLIB’ 
//TRN.SYSIN DD * 
IDENTIFICATION DIVISION (source program) 
EXEC CICS ... 
EXEC CICS ... 
//LKED.SYSIN DD * 








NAME PROG1 (R) 
/* 
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The statements shown in Example 10-6 make up the DFHEITVL cataloged procedure 
used in Example 10-5 on page 10-6. As with the other compile and link procedures, the 
result of the preprocessor, compile, and link steps, which is the load module, is placed in 
the data set identified on the SYSLMOD DD statement. 


Example 10-6 Procedure DFHEITVL - COBOL preprocessor, compile, and link 





//DFHEITVL PROC SUFFIX=1$, Suffix for translator module 
//* 

//* This procedure has been changed since CICS/ESA Version 3 

//* 

//* Parameter INDEX2 has been removed 

fl? 

// INDEX='CICSTS12.CICS', Qualifier(s) for CICS libraries 
// PROGLIB=&INDEX..SDFHLOAD, Name of output library 

Jy DSCTLIB=&INDEX. .SDFHCOB, Name of private macro/DSECT lib 
// COMPHLQ='SYS1', Qualifier(s) for COBOL compiler 
// OUTC=A, Class for print output 

ff REG=2M, Region size for all steps 
// LNKPARM='LIST,XREF', Link edit parameters 

// STUB='DFHEILIC', Link edit INCLUDE for DFHECI 
// LIB='SDFHCOB', Library 

// WORK=SYSDA Unit for work data sets 

//* This procedure contains 4 steps 

fe ‘ Exec the COBOL translator 

pe (using the supplied suffix 1$) 

ff * D:. Exec the vs COBOL II compiler 

//* Se Reblock &LIB(&STUB) for use by the linkedit step 
//* 4. Linkedit the output into data set &PROGLIB 

//* 

//* The following JCL should be used 

hip to execute this procedure 

//* 

//* //APPLPROG EXEC DFHEITVL 

//* //TRN.SYSIN DD * 

//* - 

fe . Application program 

el 

fee fe 

//* //LKED.SYSIN DD * 

//* NAME anyname (R) 

//* ea 

1 

//* Where anyname is the name of your application program. 
pe (Refer to the system definition guide for full details, 
//* including what to do if your program contains calls to 
//{* the common programming interface.) 

//* 

//TRN EXEC PGM=DFHECP&SUFFIX, 

// PARM='COBOL2', 

// REGION=&REG 


//STEPLIB DD DSN=&INDEX..SDFHLOAD, DISP=SHR 
//SYSPRINT DD SYSOUT=&0UTC 
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//SYSPUNCH DD DSN=&&SYSCIN, 

// DISP=(, PASS) , UNIT=&WORK, 

// DCB=BLKSIZE=400, 

// SPACE= (400, (400,100) 

Left 

//COB EXEC PGM=IGYCRCTL, REGION=&REG, 

// PARM='NODYNAM, LIB, OBJECT, RENT, RES, APOST, MAP, XREF' 
//STEPLIB DD DSN=&COMPHLQ. .COB2COMP, DISP=SHR 
//SYSLIB DD DSN=&DSCTLIB, DISP=SHR 

// DD DSN=&INDEX. .SDFHCOB, DISP=SHR 

// DD DSN=&INDEX. .SDFHMAC, DISP=SHR 

// DD DSN=&INDEX. .SDFHSAMP, DISP=SHR 
//SYSPRINT DD SYSOUT=&0UTC 

//SYSIN DD DSN=&&SYSCIN, DISP= (OLD, DELETE) 
//SYSLIN DD DSN=&&LOADSET, DISP=(MOD, PASS) , 
// UNIT=&WORK, SPACE= (80, (250,100) 
//SYSUT1 DD UNIT=&WORK, SPACE= (460, (350,100) 
//SYSUT2 DD UNIT=&WORK, SPACE= (460, (350,100) 
//SYSUT3 DD UNIT=&WORK, SPACE= (460, (350,100) 
//SYSUTA4 DD UNIT=&WORK, SPACE= (460, (350,100) 
//SYSUT5 DD UNIT=&WORK, SPACE= (460, (350,100) 
//SYSUT6 DD UNIT=&WORK, SPACE= (460, (350,100) 
//SYSUT7 DD UNIT=&WORK, SPACE= (460, (350,100) 
Efe 

//COPYLINK EXEC PGM=IEBGENER, COND= (7, LT, COB) 
//SYSUT1 DD DSN=&INDEX.. &LIB(&STUB) , DISP=SHR 
//SYSUT2 DD DSN=&&COPYLINK, DISP= (NEW, PASS), 
// DCB= (LRECL=80, BLKSIZE=400, RECFM=FB) , 
// UNIT=&WORK, SPACE= (400, (20,20) 
//SYSPRINT DD SYSOUT=&0UTC 

//SYSIN DD DUMMY 

//* 

//LKED EXEC PGM=IEWL, REGION=&REG, 

// PARM=' & LNKPARM', COND= (5, LT, COB) 
//SYSLIB DD DSN=&INDEX..SDFHLOAD, DISP=SHR 
// DD DSN=&COMPHLQ. .COB2CICS, DISP=SHR 
// DD DSN=&COMPHLQ. .COB2LIB, DISP=SHR 
//SYSLMOD DD DSN=&PROGLIB, DISP=SHR 

//SYSUT1 DD UNIT=&WORK, DCB=BLKSIZE=1024, 

// SPACE= (1024, (200,20) 

//SYSPRINT DD SYSOUT=&0UTC 

//SYSLIN DD DSN=&&COPYLINK, DISP= (OLD, DELETE) 
// DD DSN=&&LOADSET, DISP= (OLD, DELETE) 
// DD DDNAME=SYSIN 
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COBOL compile and link procedure 


The JCL in Example 10-7 executes the IGYWCL procedure, which is a two-step 
procedure for compiling a source program and linking it into a load library. The first step 
produces an object module that is stored in the SYSLIN temporary data set, as shown in 
Example 10-8. The second step takes the SYSLIN temporary data set as input, as well as 
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any other modules that might need to be included, and creates a load modules in the data 
set referenced by the SYSLMOD DD statement. 


The end result of running the JCL in Example 10-7 (assuming that there are no errors) 
should be to compile our inline source program, link-edit the object code and then store 
the load module called PROGI in the data set MY.LOADLIB. 


Example 10-7 Basic JCL for compiling and linking a COBOL source program inline 


/ /COMLNK JOB 
//CL EXEC IGYWCL 
//COBOL.SYSIN DD * 
IDENTIFICATION DIVISION (source program) 




















/* 
//LKED.SYSLMOD DD DSN=MY.LOADLIB(PROG1) , DISP=OLD 





The statements shown in Example 10-8 make up the IGYWCL cataloged procedure used 
in Example 10-7. As mentioned previously, the result of the compile and link steps, 
which is the load module, is placed in the data set identified on the SYSLMOD DD 
statement. 


Example 10-8 Procedure IGYWCL - COBOL compile and link 


//IGYWCL PROC LNGPRFX='IGY.V2R1M0', SYSLBLK=3200, 


































































































// LIBPRFX='CEE', 

// PGMLIB=' &&GOSET', GOPGM=GO 

//* 

//* COMPILE AND LINK EDIT A COBOL PROGRAM 

f* 

//* PARAMETER DEFAULT VALUE 

//* LNGPRFX IGY.V2R1M0 

//* SYSLBLK 3200 

yee LIBPRFX CEE 

//* PGMLIB &&GOSET DATA SET NAME FOR LOAD MODULE 
f£* GOPGM GO MEMBER NAME FOR LOAD MODULE 
//* 

//* CALLER MUST SUPPLY //COBOL.SYSIN DD ... 

//* 

//COBOL EXEC PGM=IGYCRCTL, REGION=2048K 

















//STEPLIB DD DSNAME=&LNGPRFX..SIGYCOMP, 

// DISP=SHR 

//SYSPRINT DD SyYSOUT=* 

//SYSLIN DD DSNAME=&&LOADSET, UNIT=VIO, 

// DISP= (MOD, PASS) , SPACE=(TRK, (3,3)), 
// DCB= (BLKSIZE=&SYSLBLK) 
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10-10 











































































































//SYSUT1 DD UNIT=VIO, SPACE=(CYL, (1,1)) 
//SYSUT2 DD UNIT=VIO, SPACE=(CYL, (1,1)) 
//SYSUT3 DD UNIT=VIO, SPACE=(CYL, (1,1)) 
//SYSUT4 DD UNIT=VIO, SPACE=(CYL, (1,1)) 
//SYSUT5 DD UNIT=VIO, SPACE=(CYL, (1,1)) 
//SYSUT6 DD UNIT=VIO, SPACE=(CYL, (1,1)) 
//SYSUT7 DD UNIT=VIO, SPACE=(CYL, (1,1)) 

//LKED EXEC PGM=HEWL, COND=(8,LT,COBOL) , REGION=1024K 
//SYSLIB DD DSNAME=&LIBPRFX..SCEELKED, 

// DISP=SHR 

//SYSPRINT DD SyYSOUT=* 

//SYSLIN DD DSNAME=&&LOADSET, DISP= (OLD, DELETE) 
// DD DDNAME=SYSIN 

//SYSLMOD DD DSNAME=&PGMLIB(&GOPGM) , 

// SPACE=(TRK, (10,10,1)), 

// UNIT=V1IO, DISP= (MOD, PASS) 

//SYSUTI1 DD UNIT=VIO, SPACE=(TRK, (10,10)) 

















COBOL compile, link and go procedure 

The JCL in Example 10-9 executes the IGYWCLG procedure, which is a three-step 
procedure for compiling a source program, linking it into a load library, and then 
executing the load module. The first two steps are the same as those in the compile and 
link example (Example 10-7 on page 10-9). However, whereas in Example 10-7 on 
page 10-9 we override the SYSLMOD DD statement in order to permanently save the 
load module, in Example 10-9, we do not need to save it in order to execute it. That is 
why the override to the SYSLMOD DD statement in Example 10-9 is enclosed in square 
brackets, to indicate that it is optional. 


If it is coded, then the load module PROG1 will be permanently saved in MY.LOADLIB. 
If it is not coded, then the load module will be saved in a temporary data set and deleted 
after the GO step. 


In Example 10-9, you can see that the JCL is very similar to the JCL used in the simple 
compile job (Example 10-3 on page 10-5). Looking at the JCL in Example 10-10 on 
page 10-11, the only difference between it and the JCL in Example 10-8 on page 10-9 is 
that we have added the GO step. The end result of running the JCL in Example 10-9 
(assuming that there are no errors) should be to compile our inline source program, 
link-edit the object code, store the load module (either temporarily or permanently), and 
then execute the load module. 


Example 10-9 Basic JCL for compiling, linking and executing a COBOL source program 
inline 

//CLGO JOB 

//CLG EXEC IGYWCLG 

//COBOL.SYSIN DD * 

IDENTIFICATION DIVISION (source program) 
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/* 
[//LKED.SYSLMOD DD DSN=MY.LOADLIB (PROG1) , DISP=OLD] 





The statements shown in Example 10-10 make up the IGYWCLG cataloged procedure 
used in Example 10-9 on page 10-10. 


Example 10-10 Procedure IGYWCLG - COBOL compile, link, and go 





























//IGYWCLG PROC LNGPRFX='IGY.V2R1M0',SYSLBLK=3200, 
// LIBPRFX='CEE' , GOPGM=GO 

//* 

//* COMPILE, LINK EDIT AND RUN A COBOL PROGRAM 
LL* 

//* PARAMETER EFAULT VALUE USAGE 




















D 
//* LNGPRFX IGY.V2R1M0 
//* SYSLBLK 3200 

Cc 










































































































































































Lf* LIBPRFX EE 

//* GOPGM GO 

//* 

//* CALLER MUST SUPPLY //COBOL.SYSIN DD 

Life 

//COBOL EXEC PGM=IGYCRCTL, REGION=2048K 

//STEPLIB DD DSNAME=&LNGPRFX..SIGYCOMP, 

// DISP=SHR 

//SYSPRINT DD SYSOUT=* 

//SYSLIN DD DSNAME=&&LOADSET, UNIT=VIO, 

// DISP= (MOD, PASS) , SPACE= (TRK, (3,3)), 

// DCB= (BLKSIZE=&SYSLBLK) 

//SYSUT1 DD UNIT=VIO, SPACE=(CYL, (1,1)) 

//SYSUT2 DD UNIT=VIO, SPACE=(CYL, (1,1)) 

//SYSUT3 DD UNIT=VIO, SPACE=(CYL, (1,1)) 

//SYSUT4 DD UNIT=VIO, SPACE=(CYL, (1,1)) 

//SYSUT5 DD UNIT=VIO, SPACE=(CYL, (1,1)) 

//SYSUT6 DD UNIT=VIO, SPACE=(CYL, (1,1)) 

//SYSUT7 DD UNIT=VIO, SPACE=(CYL, (1,1)) 

//LKED EXEC PGM=HEWL, COND=(8, LT, COBOL) , REGION=1024K 
//SYSLIB DD DSNAME=&LIBPRFX..SCEELKED, 

// DISP=SHR 

//SYSPRINT DD SYSOUT=* 

//SYSLIN DD DSNAME=&&LOADSET, DISP= (OLD, DELETE) 

// DD DDNAME=SYSIN 

//SYSLMOD DD DSNAME=&&GOSET (&GOPGM) , SPACE=(TRK, (10,10,1)), 
// UNIT=VIO, DISP= (MOD, PASS) 

//SYSUTI1 DD UNIT=VIO, SPACE=(TRK, (10,10)) 

//GO EXEC PGM=*.LKED.SYSLMOD, COND=((8,LT,COBOL), (4,LT, LKED) ), 
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// REGION=20 48K 
//STEPLIB DD DSNAME=&LIBPRFX..SCEERUN, 
// DISP=SHR 


//SYSPRINT DD SYSOUT=* 
//CEEDUMP DD SYSOUT=* 
//SYSUDUMP DD SYSOUT=* 

















10.3.3 Compiling object-oriented (OO) applications 


If you use a batch job or TSO/E to compile an OO COBOL program or class definition, 
the generated object code is written, as usual, to the data set that you identify with the 
SYSLIN or SYSPUNCH ddname. 


If the COBOL program or class definition uses the JNI environment structure to access 
JNI callable services, copy the file JNI.cpy from the HFS to a PDS or PDSE member 
called JNI, identify that library with a SYSLIB DD statement, and use a COPY statement 
of the form COPY JNI in the COBOL source program. 


As shown in Example 10-11, use the SYSJAVA ddname to write the generated Java 
source file to a file in the HFS. For example: 


Example 10-11 SYSJAVA ddname for a Java source file 











//SYSJAVA DD PATH='/u/userid/java/Classname.java', 
// PATHOPTS= (OWRONLY, OCREAT, OTRUNC), 

// PATHMODE=SIRWXU, 

// FILEDATA=TEXT 

















10.3.4 Object modules 


10-12 


An object module is a collection of one or more compilation units produced by an 
assembler, compiler, or other language translator, and used as input to the binder or 
linkage editor. 


An object module is in relocatable format with machine code that is not executable. A 
load module is also relocatable, but with executable machine code. A load module is in a 
format that can be loaded into virtual storage and relocated by program fetch, a program 
that prepares load modules for execution by loading them at specific storage locations. 


Object modules and load modules share the same logical structure consisting of: 


> Control dictionaries, containing information to resolve symbolic cross-references 
between control sections of different modules, and to relocate address constants. 


> Text, containing the instructions and data of the program. 
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> An end-of-module indication, which is an END statement in an object module, or an 
end-of-module indicator in a load module. 


Object modules are stored in a partitioned data set identified by the SYSLIN or 
SYSPUNCH DD statement, which is input to the next linkage edition process. 


10.3.5 Object Library 


You can use an object library to store object modules. The object modules to be 
link-edited are retrieved from the object library and transformed into an executable or 
loadable program. 


When using the OBJECT compiler option, you can store the object code on disk as a 
traditional data set or as an HFS file or on tape. The DISP parameter of the SYSLIN DD 
statement indicates whether the object code data set is to be: 


Passed to the linkage editor or binder after compile (DISP=PASS) 
Cataloged in an existent object library (DISP=OLD) 

Kept (DISP=KEEP) 

Added to a new object library, which is cataloged at the end of the step 
(DISP=CATLG) 


vvvy 


An object module can be the primary input to the binder by specifying its data set name 
and member name on the SYSLIN DD statement. In the following example, the member 
named TAXCOMP in the object library USER.LIBROUT is the primary input. 
USER.LIBROUT is a cataloged partitioned data set: 





//SYSLIN DD DSNAME=USER.LIBROUT (TAXCOMP) , DISP=SHR 











The library member is processed as if it were a sequential data set. 


10.3.6 Program management 


Although program management components provide many services, they are used 
primarily to convert object modules into executable programs, store them in program 
libraries, and load them into virtual storage for execution. 


You can use the program management binder and loader to perform these tasks. These 
components can also be used in conjunction with the linkage editor. A load module 
produced by the linkage editor can be accepted as input by the binder or can be loaded 
into storage for execution by the program management loader. The linkage editor can 
also process load modules produced by the binder. 


Figure 10-2 shows how the program management components work together, and how 
each one is used to prepare an executable program. We have already discussed some of 
these components (source and object modules), so now we take a look at the rest of them. 
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Figure 10-2. Using Program Management components to create and load programs 


10.3.7 Linkage editor 


Linkage editor processing follows the source program assembly or compilation of any 
problem program. The /inkage editor is both a processing program and a service program 
used in association with the language translators. 


Linkage editor and loader processing programs prepare the output of language translators 
for execution. The linkage editor prepares a load module that is to be brought into storage 
for execution by program fetch. 
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The linkage editor accepts two major types of input: 
> Primary input, consisting of object modules and linkage editor control statements. 


> Additional user-specified input, which can contain either object modules and control 
statements, or load modules. This input is either specified by you as input, or is 
incorporated automatically by the linkage editor from a call library. 


Output of the linkage editor is of two types: 
> A load module placed in a library (a partitioned data set) as a named member. 


> Diagnostic output produced as a sequential data set. 


The loader prepares the executable program in storage and passes control to it directly. 


Load Module Creation 

In processing object and load modules, the linkage editor assigns consecutive relative 
virtual storage addresses to control sections, and resolves references between control 
sections. Object modules produced by several different language translators can be used 
to form one load module. 


An output load module is composed of all input object modules and input load modules 
processed by the linkage editor. The control dictionaries of an output module are, 
therefore, a composite of all the control dictionaries in the linkage editor input. The 
control dictionaries of a load module are called the composite external symbol dictionary 
(CESD) and the relocation dictionary (RLD). The load module also contains the text 
from each input module, and an end-of-module indicator. 


Figure 10-3 on page 10-16 shows the process of compiling two source programs: 
PROGA and PROGB. PROGA is a COBOL program and PROGB is an Assembler 
language program. PROGA calls PROGB. In this figure we see that after compilation, 
the reference to PROGB in PROGA is an unresolved reference. The process of 
link-editing the two object modules resolves the reference so that when PROGA is 
executed, the call to PROGB will work correctly. PROGB will be transferred to, it will 
execute, and control will return to PROGA, after the point where PROGB was called. 
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Figure 10-3 Resolving references during load module creation 


Binder 

The binder performs all of the functions of the linkage editor. It link-edits, or combines 
and edits individual object modules or load modules to produce a single load module that 
is stored in a PDS program library until it is needed. Additionally, the binder can link-edit 
or bind modules into a program object that can be stored in a PDSE program library. 
When a member of a program library is needed, the loader brings it into virtual storage 
and prepares it for execution. You can use the binder to: 


> Convert object or load modules, or program objects, into a program object and store 
the program object in a partitioned data set extended (PDSE) program library or in an 
z/OS UNIX file. 

> Convert object or load modules, or program objects, into a load module and store the 
load module in a partitioned data set (PDS) program library. This is equivalent to 
what the linkage editor can do with object and load modules. 


> Convert object or load modules, or program objects, into an executable program in 
virtual storage and execute the program. This is equivalent to what the batch loader 
can do with object and load modules. 


The binder processes object modules, load modules and program objects, link-editing or 
binding multiple modules into a single load module or program object. Control 
statements specify how to combine the input into one or more load modules or program 
objects with contiguous virtual storage addresses. Each object module can be processed 
separately by the binder, so that only the modules that have been modified need to be 
recompiled or reassembled. The binder can create programs in 24-bit, 31-bit and 64-bit 
addressing ranges. 


You assign an addressing mode (AMODE) to indicate which hardware addressing mode 
is active when the program executes. Addressing modes are: 
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24, which indicates that 24-bit addressing must be in effect. 

31, which indicates that 31-bit addressing must be in effect. 

64, which indicates that 64-bit addressing must be in effect. 

ANY, which indicates that 24-bit, 31-bit, or 64-bit addressing can be in effect. 

MIN, which requests that the binder assign an AMODE value to the program module. 


vvvvy 


The binder selects the most restrictive AMODE of all control sections in the input to the 
program module. An AMODE value of 24 is the most restrictive; an AMODE value of 
ANY is the /east restrictive. 


All of the services of the linkage editor can be performed by the binder. 


Refer to 2.3.6, “Brief history of virtual storage and addressability” on page 2-9 for more 
information on the layout of an address and which areas of the address space are 
addressable by 24 bits, 31 bits and 64 bits. 


Binder and linkage editor 

The binder relaxes or eliminates many restrictions of the linkage editor. The binder 
removes the linkage editor's limit of 64 aliases, allowing a load module or program object 
to have as many aliases as desired. The binder accepts any system-supported block size 
for the primary (SYSLIN) input data set, eliminating the linkage editor's maximum block 
size limit of 3200 bytes. The binder also does not restrict the number of external names, 
whereas the linkage editor sets a limit of 32767 names. 


With the binder, you no longer need to pre-link, because the binder handles all of the 
functionality of the pre-linker. Whether you use the binder or linkage editor is a matter of 
preference. The binder is the newest and most up-to-date way to create your load module. 


The primary input, required for every binder job step, is defined on a DD statement with 
the ddname SYSLIN. Primary input can be: 


A sequential data set 

A member of a partitioned data set (PDS) 

A member of a partitioned data set extended (PDSE) 

Concatenated sequential data sets, or members of partitioned data sets or PDSEs, or a 
combination 

> Az/OS UNIX file 


vvvy 


The primary data set can contain object modules, control statements, load modules and 
program objects. All modules and control statements are processed sequentially, and their 
order determines the order of binder processing. The order of the sections after 
processing, however, might not match the input sequence. 
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Binder example 

Example 10-12 link-edits an object module. The output from the LKED step will be 
placed in a private library identified by the SYSLMOD DD. The input is passed from a 
previous job step to a binder job step in the same job (for example, the output from the 
compiler is direct input to the binder). 


Example 10-12 Binder JCL example 




































































//LKED EXEC PGM=IEWL, PARM='XREF,LIST', IEWL is IEWBLINK alias 
Ji REGION=2M, COND= (5, LT, prior-step) 
i{* 
//* Define secondary input 
LL® 
//SYSLIB DD DSN=language.library, DISP=SHR optional 
//PRIVLIB DD DSN=private.include.library, DISP=SHR optional 
//SYSUTL DD UNIT=SYSDA, SPACE=(CYL, (1,1) ) ignored 
Lee 
piper Define output module library 
Lf* 
//SYSLMOD DD DSN=program.library, DISP=SHR required 
//SYSPRINT DD SYSOUT=* required 
//SYSTERM DD SYSOUT=* optional 
Lf® 
/1[* Define primary input 
Li 
//SYSLIN DD DSN=&&OBJECT, DISP= (MOD, PASS) required 
// DD * inline control statements 

INCLUDE PRIVLIB(membername) 

NAME modname (R) 
/* 


An explanation of the JCL statements follows: 


EXEC 


SYSUTI 


SYSLMOD 
SYSPRINT 


SYSLIN 


INCLUDE 
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Binds a program module and stores it in a program library. Alternative 
names for IEWBLINK are IEWL, LINKEDIT, HEWL, and HEWLH096. 
The PARM field option requests a cross-reference table and a module 
map to be produced on the diagnostic output data set. 


Defines a temporary direct access data set to be used as the intermediate 
data set. 


Defines a temporary data set to be used as the output module library. 


Defines the diagnostic output data set, which is assigned to output class 
A. 


Defines the primary input data set, & & OBJECT, which contains the input 
object module; this data set was passed from a previous job step and is to 
be passed at the end of this job step. 


Specifies sequential data sets, library members, or z/OS UNIX files that 
are to be sources of additional input for the binder (in this case, a member 
of the private library PRIVLIB). 
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NAME Specifies the name of the program module created from the preceding 
input modules, and serves as a delimiter for input to the program module. 
(R) indicates that this program module replaces an identically named 
module in the output module library. 


10.4 Creating load modules for executable programs 


A load module is an executable program stored in a partitioned data set program library. 
Creating a load module to execute only, will require that you use a batch loader or 
program management loader. Creating a load module that can be stored in a program 
library requires that you use the binder or linkage editor. In all cases, the load module is 
relocatable, which means that it can be located at any address in virtual storage within the 
confines of the residency mode (RMODE). 


Once a program is loaded, control is passed to it, with a value in the base register. This 
gives the program its starting address, where it was loaded, so that all addresses can be 
resolved as the sum of the base plus the offset. Relocatable programs allow an identical 
copy of a program to be loaded in many different address spaces, each being loaded at a 
different starting address. See 10.3, “Compiling programs on z/OS” on page 10-3 for 
more discussion on relocatable programs. 


10.4.1 Batch loader 


The batch loader combines the basic editing and loading services (which can also be 
provided by the linkage editor and program fetch) into one job step. The batch loader 
accepts object modules and load modules, and loads them into virtual storage for 
execution. Unlike the binder and linkage editor, the batch loader does not produce load 
modules that can be stored in program libraries. The batch loader prepares the executable 
program in storage and passes control to it directly. 


Batch loader processing is performed in a load step, which is equivalent to the link-edit 
and go steps of the binder or linkage editor. The batch loader can be used for both 
compile-load and load jobs. It can include modules from a call library (SYSLIB), the link 
pack area (LPA), or both. Like the other program management components, the batch 
loader supports addressing and residence mode attributes in the 24-bit, 31-bit, and 64-bit 
addressing ranges. The batch loader program is reentrant and therefore can reside in the 
resident link pack area. 


Note: The batch loader is replaced by the binder in z/OS. 
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10.4.2 Program management loader 


The program management loader increases the services of the program fetch component 
by adding support for loading program objects. The loader reads both program objects 
and load modules into virtual storage and prepares them for execution. It resolves any 
address constants in the program to point to the appropriate areas in virtual storage and 
supports the 24-bit, 31-bit and 64-bit addressing ranges. 


In processing object and load modules, the linkage editor assigns consecutive relative 
virtual storage addresses to control sections and resolves references between control 
sections. Object modules produced by several different language translators can be used 
to form one load module. 


In Example 10-13 we have a compile, link-edit, and execute job, in this case for an 
assembler program. 


Example 10-13 Compile, link-edit, and execute JCL 














//USUAL JOB A2317P,'COMPLGO'! 

//ASM EXEC PGM=IEV90,REGION=256K, EXECUTES ASSEMBLER 

// PARM= (OBJECT, NODECK, 'LINECOUNT=50' 

//SYSPRINT DD SYSOUT=*, DCB=BLKSIZE=3509 PRINT THE ASSEMBLY LISTING 

//SYSPUNCH DD SYSOUT=B PUNCH THE ASSEMBLY LISTING 

//SYSLIB DD DSNAME=SYS1.MACLIB, DISP=SHR THE MACRO LIBRARY 

//SYSUT1 DD DSNAME=&&SYSUT1, UNIT=SYSDA, A WORK DATA SET 

// SPACE= (CYL, (10,1) 

//SYSLIN DD DSNAME=&&OBJECT, UNIT=SYSDA, THE OUTPUT OBJECT MODULE 

// SPACE=(TRK, (10,2) ) , DCB=BLKSIZE=3120, DISP=(, PASS) 

//SYSIN DD * inline SOURCE CODE 
code 

/* 

//LKED EXEC PGM=HEWL, EXECUTES LINKAGE EDITOR 

// PARM='XREF, LIST, LET', COND= (8, LE, ASM) 

//SYSPRINT DD SYSOUT=* LINKEDIT MAP PRINTOUT 

//SYSLIN DD DSNAME=&&OBJECT, DISP=(OLD, DELETE) INPUT OBJECT MODULE 

//SYSUT1 DD DSNAME=&&SYSUT1, UNIT=SYSDA, A WORK DATA SET 

// SPACE= (CYL, (10,1) 

//SYSLMOD DD DSNAME=& & LOADMOD, UNIT=SYSDA, THE OUTPUT LOAD MODULE 

// DISP= (MOD, PASS) , SPACE= (1024, (50,20,1) 

//GO EXEC PGM=*.LKED.SYSLMOD, TIME=(,30), EXECUTES THE PROGRAM 

// COND=((8,LE,ASM) , (8, LE, LKED) ) 

//SYSUDUMP DD SYSOUT=* IF FAILS, DUMP LISTING 

//SYSPRINT DD SYSOUT=*, OUTPUT LISTING 

// DCB= (RECFM=FBA, LRECL=121) 

//OUTPUT DD SYSOUT=A, PROGRAM DATA OUTPUT 

// DCB= (LRECL=100, BLKSIZE=3000, RECFM=FBA) 

//INPUT DD * PROGRAM DATA INPUT 
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data 


/* 
// 


Notes: 


> In the step ASM (compile), SYSIN DD is for the inline source code and SYSLIN 
DD is for the output object module. 

> In the step LKED (linkage-edition), the SYSLIN DD is for the input object 
module and the SYSLMOD DD is for the output load module. 

> Inthe step GO (execute the program), the EXEC JCL statement states that it will 
execute a program identified in the SYSLMOD DD statement of the previous step. 

> This example does not use a cataloged procedure, as the COBOL examples did; 
instead, all of the JCL has been coded inline. We could have used an existing JCL 
procedure, or coded one and then only supplied the overrides, such as the INPUT 
DD statement. 


10.4.3 Load library 


A load library is a library that contains programs ready to be executed. A load library can 
be one of the following: 


> System library 
> Private library 
> Temporary library 


System Library 


Unless a job or step specifies a private library, the system searches for a program in the 
system libraries when you code: 











//stepname EXEC PGM=program-name 





The system looks in the libraries for a member with a name or alias that is the same as the 
specified program-name. The most-used system library is SYS1.LINKLIB, which 
contains executable programs that have been processed by the linkage editor. Refer to 
17.3, “z/OS System Libraries” on page 17-8 for more information on system libraries. 


Private Library 


Each executable, user-written program is a member of a private library. To tell the system 
that a program is in a private library, the DD statement defining that library can be coded 
in one of the following ways: 


> With a DD statement with the ddname JOBLIB after the JOB statement, and before 
the first EXEC statement in the job 
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> Ifthe library is going to be used in only one step, with a DD statement with the 
ddname STEPLIB in the step 


To execute a program from a private library, code: 


//stepname EXEC PGM=program-name 


When you code JOBLIB or STEPLIB, the system searches for the program to be 
executed in the library defined by the JOBLIB or STEPLIB DD statement before 
searching in the system libraries. 


If an earlier DD statement in the job defines the program as a member of a private library, 
refer to that DD statement to execute the program: 


//stepname EXEC PGM=*.stepname.ddname 


Private libraries are particularly useful for programs used too seldom to be needed in a 
system library. For example, programs that prepare quarterly sales tax reports are good 
candidates for a private library. 


Temporary library 
Temporary libraries are partitioned data sets created to store a program until it is used in 
a later step of the same job. A temporary library is created and deleted within a job. 


When testing a newly written program, a temporary library is particularly useful for 
storing the load module from the linkage editor until it is executed by a later job step. 
Because the module will not be needed by other jobs until it is fully tested, it should not 
be stored in a private library or a system library. In Example 10-13 on page 10-20, the 
LKED step creates a temporary library called &&LOADMOD on the SYSLMOD DD 
statement. In the GO step, we refer back to the same temporary data set by coding: 


//G0 EXEC PGM=*.LKED.SYSLMOD,.... 


10.5 Example from compilation to execution 


10-22 


In Figure 10-4, we can see the relationship between the object modules and the load 
module stored in a load library and then loaded into central memory for execution. 


We start with two programs, A and B, which are compiled into two object modules. Then 
the two object modules are linked into one load module call MYPROG, which is stored in 
a load library on direct access storage. The load module MYPROG is then loaded into 
central storage by the program management loader, and control is transferred to it to for 
execution. 
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Figure 10-4 Program compile, link-edit, and execution 


10.6 Procedures 


To save time and prevent errors, you can prepare sets of job control statements and place 
them in a partitioned data set (PDS) or partitioned data set extended (PDSE), known as a 
procedure library. This can be used, for example, to compile, assemble, link-edit, and 
execute a program, as we have seen in Example 10-13 on page 10-20. For a more 
in-depth discussion on JCL procedures, see 5.10, “JCL procedures (PROC)” on 
page 5-14. 


A procedure library is a library that contains procedures. See 5.13, “System libraries” on 
page 5-20 for more discussion on SYS1.PROCLIB. A set of job control statements in the 
system procedure library, SYS1.PROCLIB (or an installation-defined procedure library), 
is called a cataloged procedure. 


To test a procedure before placing it in a procedure library, place it in the input stream 
and execute it; a procedure in the input stream is called an inline procedure. The 
maximum number of inline procedures you can code in any job is 15. In order to test a 
procedure in the input stream, it must end with a procedure end (PEND) statement. The 
PEND statement signals the end of the PROC. This is only required when the procedure 
is coded inline. In a procedure library, we do not require a PEND statement. 
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An inline procedure must appear in the same job before the EXEC statement that calls it. 


Example 10-14 Sample definition of a procedure 
























































//DEF PROC STATUS=OLD, LIBRARY=SYSLIB, NUMBER=777777 
//NOTIFY EXEC PGM=ACCUM 

//DD1 DD DSNAME=MGMT, DISP=(&STATUS, KEEP) , UNIT=3400-6, 
// VOLUME=SER=8 88888 

//DD2 DD DSNAME=&LIBRARY, DISP= (OLD, KEEP) , UNIT=3350, 
// VOLUME=SER=&NUMBER 

















Three symbolic parameters are defined in the cataloged procedure shown in 
Example 10-14: &STATUS, & LIBRARY, and &NUMBER. Values are assigned to the 
symbolic parameters on the PROC statement. These values are used if the procedure is 
called and no values are assigned to the symbolic parameters on the calling EXEC 
statement. 


In Example 10-15 we are testing the procedure called DEF. Note that the procedure is 
delineated by the PROC and PEND statements. The EXEC statement that follows the 
procedure DEF references the procedure to be invoked. In this case, since the name DEF 
matches a procedure that was previously coded inline, the system will use the procedure 
inline and will not search any further. 


Example 10-15 Testing a procedure inline 






















































































//TESTJOB JOB 

//DEF PROC STATUS=OLD, LIBRARY=SYSLIB, NUMBER=777777 
//NOTIFY EXEC PGM=ACCUM 

//DD1 DD DSNAME=MGMT, DISP=(&STATUS, KEEP) , UNIT=3400-6, 
// VOLUME=SER=8 88888 

//DD2 DD DSNAME=&LIBRARY, DISP=(OLD, KEEP) , UNIT=3350, 
Ly VOLUME=SER=&NUMBER 

// PEND 

//* 

//TESTPROC EXEC DEF 

// 


10.7 Summary 


10-24 


This chapter details the process for translating a source program into an executable load 
module, and then executing the load module. The basic steps for this translation are to 
compile and link-edit, although there might be a third step to pre-process the source prior 
to compiling it. The pre-processing step would be required if your source program issues 
CICS command language calls or SQL calls. The output of the pre-processing step is 
then fed into the compile step. 
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The purpose of the compile step is to validate and translate source code into relocatable 
machine language, in the form of object code. Although the object code is machine 
language, it is not yet executable. It must first be processed by a linkage-editor, binder, or 
loader before it can be executed. 


The linkage-editor, binder, and loader take as input object code and other load modules, 
and then produce an executable load module and, in the case of the loader, to execute it. 
This process resolves any unresolved references within the object code and ensures that 
everything that is required for this program to execute is included within the final load 
module. The load module is now ready for execution. 


To execute a load module, it must be loaded into central storage. The binder or program 
fetch service will load a module into storage and then transfer control to it to begin 
execution. Part of transferring control to the module is to supply it with the address of the 
start of the program in storage. Because the program’s instructions and data are addressed 
using a base address and a displacement from the base, this starting address gives 
addressability to the instructions and data within the limits of the range of displacement!, 




















Key terms in this chapter 

binder copybook linkage-editor 

load module object module object-oriented code 
procedure procedure library program library 
relocatable source module 


























10.8 Discussion questions 


What are the steps needed to be able to execute a source program? 
How can I modify an object module? A load module? 

How many different types of load libraries can the system have? 
In a z/OS UNIX system, what is the equivalent to a z/OS data set? 
What is a procedure library, and what is it used for? 


What is the difference between the linkage editor and the binder? 


mM OD Se eS 


How are copybooks and cataloged procedure libraries similar? 


' The maximum displacement for each base register is 4096 (4K). Any program bigger than 4K must have 
more than one base register in order to have addressability to the entire program. 
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10.9 Exercises 


What is the purpose of a compiler? What are the inputs and outputs? 

What does relocatable mean? 

What is the difference between an object module and a load module? 

In z/OS, what service has replaced the batch loader? 

What is the SYSLMOD DD statement used for? 

Why is a PEND statement required in an inline PROC and not in a cataloged PROC? 


NS a BS NM 


10.9.1 Compiling and linking language programs 


In this section, select at least two of the example languages to compile and link using the 
JCL in: 


yourid.LANG.CNTL(language) 
where “language” is one of ASM, ASMLE, C, C2, COBOL, COBOL2, PL1, PL12. 


This exercise is a prerequisite to the exercise 10.9.2, “Executing language programs” on 
page 10-28. The results of successfully running each job in this exercise will be to create 
the load modules which will be executed in the next exercise. 


Note: The JCL will need to be modified to specify the high-level qualifier (HLQ) of 
the student submitting the jobs. In addition, any jobs referring to Language 
Environment data sets might also need to be modified. See the comment boxes for 
more information. 


To submit the jobs, enter SUBMIT on the ISPF command line. Once the job 


completes, you will need to use SDSF to view the output of the job. 


7. Submit the following data set to compile and link a complex Assembler language 
program: 


yourid.LANG.CNTL(ASMLE) 
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Note: The student might need to modify the JCL for data sets beginning with 
CEE. Ask your system programmer what the high-level qualifier (HLQ) is for the 
Language Environment data sets. The JCL that might need to be changed is 


highlighted here: 
//C.SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR 
Hil DD DSN=CEE.SCEEMAC,DISP=SHR 
//C.SYSIN DD DSN=ZUSER##. LANG. SOURCE (ASMLE) , DISP=SHR 


//L.SYSLMOD DD DSN=ZUSER##.LANG.LOAD(ASMLE) ,DISP=SHR 
//L.SYSLIB DD DSN=CEE.SCEELKED, DISP=SHR 
// DD DSN=CEE.SCEELKEX, DISP=SHR 


8. Submit the following data set to compile and link a simple Assembler language 
program: 


yourid.LANG.CNTL (ASM) 
9. Submit the following data set to compile and link a complex C language program: 
yourid.LANG.CNTL(C) 


Note: The student might need to modify the JCL for data sets beginning with CEE 
and CBC. Ask your system programmer what the high-level qualifiers (HLQs) are 
for the Language Environment and C language data sets. The JCL that might need 
to be changed is highlighted here: 


//STEP1 EXEC PROC=EDCCB,LIBPRFX=CEE, LNGPRFX=CBC, 
// INFILE='ZUSER##.LANG.SOURCE(C) ', 
// OUTFILE='ZUSER##.LANG.LOAD(C) ,DISP=SHR' 


10. Submit the following data set to compile and link a simple C language program: 
yourid. LANG. CNTL(C2) 


Note: The student might need to modify the JCL for data sets beginning with CEE 
and CBC. Ask your system programmer what the high-level qualifiers (HLQs) are 
for the Language Environment and C language data sets. The JCL that might need 
to be changed is highlighted here: 


//STEP1 EXEC PROC=EDCCB,LIBPRFX=CEE, LNGPRFX=CBC, 
// INFILE='ZUSER##.LANG.SOURCE(C2)', 
// OUTFILE='ZUSER##.LANG.LOAD(C2) ,DISP=SHR' 


11. Submit the following data set to compile and link a complex COBOL language 


program: 


yourid.LANG.CNTL (COBOL) 
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Note: The student might need to modify the JCL for data sets beginning with 
CEE. Ask your system programmer what the high-level qualifier (HLQ) is for the 
Language Environment data sets. The JCL that might need to be changed is 
highlighted here: 


//SYSIN DD DSN=ZUSER##. LANG. SOURCE (COBOL) ,DISP=SHR 
//COBOL.SYSLIB DD DSN=CEE.SCEESAMP,DISP=SHR 
//LKED.SYSLMOD DD DSN=ZUSER##.LANG.LOAD (COBOL) ,DISP=SHR 


12. Submit the following data set to compile and link a simple COBOL language 
program: 
yourid.LANG.CNTL(COBOL2) 

13. Submit the following data set to compile and link a complex PL/I language program: 
yourid.LANG.CNTL(PL1) 


Note: The student might need to modify the JCL for data sets beginning with 
CEE. Ask your system programmer what the high-level qualifier (HLQ) is for the 
Language Environment data sets. The JCL that might need to be changed is 
highlighted here: 


//SYSIN DD DSN=ZUSER##.LANG.SOURCE(PL1) ,DISP=SHR 
//PLI.SYSLIB DD DSN=CEE.SCEESAMP,DISP=SHR 
//BIND.SYSLMOD DD DSN=ZUSER##.LANG.LOAD(PL1) ,DISP=SHR 


14. Submit the following data set to compile and link a simple PL/I language program: 
yourid.LANG.CNTL(PL12) 


10.9.2 Executing language programs 


In this section, language examples you selected were compiled and linked in exercise 
“Compiling and linking language programs” on page 10-26. 


Note: Do not attempt to run any of the following jobs if you have not successfully 
completed the previous exercise, because they will end in errors. 


The following exercise contains actions to perform for each language sample to execute 
the load module that was previously stored when a compile and link job was run. For the 
interpreted languages, you will execute the source members directly from: 


yourid.LANG.SOURCE(language) 
where “language” is one of CLIST, REXX. 
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Note: The JCL will need to be modified to specify the HLQ of the student submitting 
the jobs. To submit the jobs, enter SUBMIT on the ISPF command line. Once the job 
completes, you will need to use SDSF to view the output of the job. 


In order for these jobs to run successfully, the student will have had to complete the 
compile and link jobs in exercise 10.9.1, “Compiling and linking language programs” 
on page 10-26 in order to create the load modules in: 


ZPROF .LANG. LOAD 


If these jobs did not run successfully, then the student could receive errors in the 
joblog in SDSF similar to: 


CSV0031 REQUESTED MODULE ASM NOT FOUND 

CSV0281 ABEND806-04 JOBNAME=ZPROF2 STEPNAME=STEP1 
IEA995I SYMPTOM DUMP OUTPUT 238 

SYSTEM COMPLETION CODE=806 REASON CODE=00000004 


The module name, JOBNAME and STEPNAME vary, according to which job had 
been submitted. 


15. Submit the following data set to execute a complex Assembler language program: 


yourid.LANG.CNTL(USEASMLE) 
This example establishes an LE environment and prints out the message: 
“IN THE MAIN ROUTINE”. 


16. Submit the following data set to execute a simple Assembler language program: 


yourid.LANG.CNTL(USEASM) 
This example sets the return to 15 and exits. 


17. Submit the following data set to execute a complex C language program: 


yourid.LANG.CNTL(USEC) 
This example prints out the local date and time. 


18. Submit the following data set to execute a simple C language program: 


yourid.LANG.CNTL(USEC2) 
This example prints out the message “Hello World”. 


19. Submit the following data set to execute a complex COBOL language program: 


yourid.LANG.CNTL(USECOBOL) 
This example prints out the local date and time. 


20. Submit the following data set to execute a simple COBOL language program: 


yourid.LANG.CNTL(USECOB02) 
This example prints out the message “HELLO WORLD”. 


21. Submit the following data set to execute a complex PL/I language program: 
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10-30 


22. 


23, 


24, 


25. 


26. 


yourid.LANG.CNTL(USEPL1) 
This example prints out the local date and time. 


Submit the following data set to execute a simple PL/I language program: 


yourid.LANG.CNTL(USEPL12) 
This example prints out the message “HELLO WORLD”. 


Execute the following complex CLIST language program: 


yourid.LANG.SOURCE(CLIST) 
This example prompts the user for a high-level qualifier (HLQ) and then 
produces a formatted catalog listing for that HLQ. 


On the ISPF command line type: 
TSO EX ‘yourid.LANG.SOURCE(CLIST) ’ 
When prompted, enter the HLQ yourid 


Execute the following simple CLIST language program: 


yourid.LANG.SOURCE(CLIST2) 
This example prints out the message “HELLO WORLD”. 


On the ISPF command line type: 
TSO EX ‘yourid. LANG.SOURCE(CLIST2) ’ 


Execute the following complex REXX language program: 


yourid.LANG. SOURCE (REXX) 
This example prompts the user for a high-level qualifier (HLQ) and then 
produces a formatted catalog listing for that HLQ. 


On the ISPF command line type: 
TSO EX ‘yourid.LANG.SOURCE(REXX) ’ 
When prompted, enter the HLQ yourid 


Execute the following simple REXX language program: 
yourid.LANG. SOURCE (REXX2) 
This example prints out the message “HELLO WORLD”. 


On the ISPF command line type: 
TSO EX ‘yourid.LANG.SOURCE (REXX2) * 
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10.10 Instructor notes 


Answers to 10.8, “Discussion questions” on page 10-25 


if 


The steps necessary to be able to execute a coded program (source) are: 


— Optionally run the source through the pre-compiler. 

— Compile the source code, yielding an object module. 

— Link-edit the object module into a load module. 

— Load the load module (execute on an EXEC PGM= JCL statement)—a load 
module must be in central storage in order to execute it. 


To modify an object module, you must modify the source code and then recompile it. 
To modify a load module, you must modify the input to the linkage editor and relink 
the object module. 


The different types of load libraries are: 


— System 
— Private 
— Temporary 


A file is the UNIX equivalent to a z/OS data set. 


A procedure library is a stored set of JCL statements for processes that are executed 
repeatedly. The JCL is stored in a procedure library in order to avoid coding the JCL 
each time that it is needed. 


The binder has all of the functionality of the linkage-editor. In addition, it can 
link-edit and bind object modules into a program object. 


A copybook is a source library containing pre-written text. A cataloged procedure 
library is a JCL library containing pre-written JCL. A copybook is referenced by 
statements in a source program that tell the compiler to insert a member of a 
copybook into the source. A cataloged procedure is referenced by specifying the 
procedure name in JCL on an EXEC statement. The system inserts the named 
procedure into the JCL. The reasons for using a copybook and a cataloged procedure 
are similar: 


— They are used repeatedly. 
— They are time savers. They also prevent errors by ensuring that each time they are 
used, the same text (JCL) will be used. 


Answers to 10.9, “Exercises” on page 10-26 


1. 


A compiler takes a source program as input and translates the source program into 
object code, which is the output of the compiler. The compiler also produces 
diagnostic messages regarding the source code that is compiled. 


Relocatable means that an identical copy of the load module can be loaded into many 
different address spaces, each loaded at a different starting address and still execute. 
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The load module can be located at any address in virtual storage within the confines 
of the residency mode (RMODE). 


3. Both an object module and a load module are in relocatable format with machine 
code, but a load module is executable and an object module is not executable. 


4. The binder has replaced the batch loader in z/OS. 


5. When link-editing a load module, the SYSLMOD DD statement is used to indicate in 
which data set (and optionally, in which member name within the data set) the load 
module is stored. 


6. Since an inline PROC is situated in JCL that is to be executed, we need something to 
signal the end of the inline PROC and the beginning of the JCL to be executed. 
Without a PEND, the system would not know which JCL was part of the PROC and 
which was not. In a catalogued PROC, the end of the PROC is the end of the member, 
so we do not need a PEND statement. 


7. - 14.) The correct answer for these exercises is to have a job that had a return code of 0 
for both the compile and link steps. This can be seem by looking in the joblog in SDSF. A 
sample is listed below, but the actual look of the joblog will change from one installation 
to another, so the headings might vary greatly. 


TEF4031I ZPROFC - STARTED - TIME=11.11.13 
-JOBNAME STEPNAME PROCSTEP RC EXCP 
-ZPROFC STEP1 COMPILE 00 = = 1201 
-ZPROFC STEP1 BIND 00 224 


15. - 22.) With the exception of the simple Assembler language program, all of the jobs 
should finish with a return code of 0. The simple Assembler language program should 
have a return code of 15. 


23.) This CLIST provides a formatted listing of the catalog for the HLQ that is entered 
when prompted. A sample is listed here: 


DATASET ZPROF.BRODCAST IS ON VOLUME TOTSTD 

DATASET ZPROF.HFS IS ON VOLUME TOTSTV 

DATASET ZPROF.INST.CNTL IS ON VOLUME TOTSTA 

DATASET ZPROF.LOG.MISC IS ON VOLUME TOTST4 

DATASET ZPROF.SCO4.ISPF42.ISPPROF IS ON VOLUME TOTST5 
DATASET ZPROF.SCO4.SPFLOG1.LIST IS ON VOLUME TOTSTO 
DATASET ZPROF.SCO4.SPFTEMPO.CNTL IS ON VOLUME TOTSSN 
DATASET ZPROF.ZSCHOLAR.$INDEX IS ON VOLUME TOTTS4 
DATASET ZPROF.ZSCHOLAR.$INDEX.DEVELOP IS ON VOLUME TOTSSJ 
DATASET ZPROF.ZSCHOLAR.AREA.CODES IS ON VOLUME TOTTSU 
DATASET ZPROF.ZSCHOLAR.CLASS.LOAD IS ON VOLUME TOTSTJ 


DATASET ZPROF.ZSCHOLAR.LIB.SOURCE IS ON VOLUME TOTSSA 


DATASET ZPROF.ZSCHOLAR.PROCLIB IS ON VOLUME TOTTSN 
DATASET ZPROF.ZSCHOLAR.PROCLIB.XMIT IS ON VOLUME TOTSSK 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter10 compiling.fm 


DATASET ZPROF.ZSCHOLAR.PROGRAM.LOAD IS ON VOLUME TOTTSO 
DATASET ZPROF.ZSCHOLAR.SORT.CNTL IS ON VOLUME TOTSSK 
DATASET ZPROF.ZSCHOLAR.SPUFI.CNTL IS ON VOLUME TOTST2 
DATASET ZPROF.ZSCHOLAR.SPUFI.OUTPUT IS ON VOLUME TOTSTG 
24.) Displays “HELLO WORLD.” 
25.) The output is the same as in 23. 


26.) The output is the same as in 24. 
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Part 3 


Online applications on z/OS 


In this part we discuss the major types of workloads performed by the z/OS operating 
system, including a few of the most popular middleware products that involve databases 
and transactions. 


© Copyright IBM Corp. 2004. All rights reserved. 
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Overview of online applications and 
databases on z/OS 








Objective: This chapter introduces some new terminology such as 
transaction, database, etc. This will help you in the next chapters. 


In this chapter, you will learn: 
> How an application evolves 
> What a transaction system is 


> What a database is 

















We have seen the batch processing possibilities, but those are not the only applications 
running on z/OS. We also have online applications, which we illustrate with an example. 
We also describe what online applications, or transactions, are and what their principles 
are. We look to another way of storing application data, a way that makes development a 
lot easier—surely if we move to a Relational Database Management System. 


This chapter also introduces the use of databases. 
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11.1 An example: the global picture 


11-2 


A big travel agency has had a mainframe system for many years. They deliver excellent 
service through the years, because they are continuously improving their systems. This is 
their history. 


Initially they designed some applications for their needs: their employee information, 
general customer information, the contacts with car rentals, hotels all over the world, the 
scheduled flights of different airlines, etc. That data is not static, so they needed a way to 
update small amounts of data that was provided in bits and pieces—some by phone, some 
by fax, later on also e-mail, etc. 


Therefore, the option was taken to create some new applications. If this were to be done 
in batch, it would mean a certain time lapse between the reception of the change and the 
actual update. The application needed to be transactional, that is, the change needed to be 
immediately reflected to the users of the application. 


Since prices, for example, change frequently, it became harder and harder to maintain 
current information. The customer wanted his information now and that was not always 
possible (consider the time difference between Asia, Europe and America). 


The travel agency contacted its suppliers to see what could be done. They needed a way 
to let the computers talk to each other. Some of the airlines were also working on 
mainframes, others were not, and everybody wanted to keep their own applications. 


They did find a solution! It made communicating easy: you could just ask a question and 
some seconds later get the result—great stuff. 


Some more innovations were required because the customers also evolved. The personal 
computer got into their homes, so they wanted to see travel possibilities via the Internet. 
Some used their mobile computers as Wireless Access Point (WAP). 


Figure 11-1 illustrates the current situation. 
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Figure 11-1 A practical example 


11.2 Transactional systems 


Transactions occur in everyday life: when you exchange money for goods and services or 
when you do a search on the Internet. A transaction is a routine event, usually a request, 
in running the day-to-day operations of an organization. 


Transactions have the following characteristics: 

> A small amount of data is processed and transferred per transaction. 

> Large numbers of users are involved in large numbers of transactions. 

A business transaction is a self-contained business deal. Some transactions involve a 
short conversation (for example, an address change). Others involve multiple actions that 


take place over an extended period (for example, the booking of a trip, including car, 
hotel and airline tickets). 
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11.2.1 Transactional systems: requirements 


In a transactional system, transactions must comply with four primary requirements 
known jointly by the mnemonic A-C-I-D or ACID: 


> Atomicity. The processes performed by the transaction are done as a whole or not at 
all. 

> Consistency. The transaction must work only with consistent information. 

> Isolation. The processes coming from two or more transactions must be isolated from 
one another. 

> Durability. The changes made by the transaction must be permanent. 


Usually, transactions are initiated by an end user who interacts with the transactional 
system through a terminal. In the past, transactional systems supported only terminals 
and devices connected through a teleprocessing network. Today, transactional systems 
can serve requests submitted in any of the following ways: 


Web page 

Remote workstation program 

Application in another transactional system 
Triggered automatically at a predefined time 


vvvy 


11.2.2 Transactional systems: some terms 
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A single transaction might consist of many application programs that, when run, carry 
out the processing needed. Large-scale transactional systems (for example CICS and 
IMS) rely on multitasking and multithreading to allow more than one task to be 
processed at the same time, each task saving its specific variable data and keeping track 
of the instructions each user is executing. 


Multitasking is essential in any environment in which thousands of users can be logged 
in at the same time. When a multitasking transactional system receives a request to run a 
transaction, it can start a new task that is associated with one instance of the execution of 
the transaction. That is, one execution of a transaction, with a particular set of data, 
usually on behalf of a particular user at a particular terminal. You might also consider a 
task to be analogous to a thread. When the transaction completes, the task is terminated. 


Multithreading allows a single copy of an application program to be processed by several 
transactions concurrently. Multithreading requires that all transactional application 
programs be reentrant; that is they must be serially reusable between entry and exit 
points. Among programming languages, reentrance is ensured by a fresh copy of working 
storage section being obtained each time the program is invoked. 


Figure 11-2 shows the main characteristics of a transactional system. Before the advent 
of the Internet, a transactional system served hundreds or thousands of terminals with 
dozens or hundreds of transactions per second. This workload was rather predictable both 
in transaction rate and mix of transactions. The actual transactional systems must be able 
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to support an unpredictable number of concurrent users and transaction types. It can be 
expected that most of the transactions executed in the system are executed repetitively 
considering short periods of time; fractions of a second in some cases. 


{ 





Figure 11-2 Characteristics of a transactional system 


One of the main characteristics of a transactional or online system is that the interactions 
between the user and the system are very short. The user requires a good response time in 
each interaction. The user will perform a complete business transaction through different 
short interactions. These systems are currently supporting mission-critical applications, 
so continuous availability, high performance and data protection and integrity are 
required. 


Online transaction processing (OLTP) is transactional processing that occurs in real time 
and requires: 


> Quick response time 
> Continuous availability of the transactional interface to the end user 
> Security 
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> Integrity 


Online transactions are familiar to many people. Some examples include: 


> ATM machine transactions such as deposits, withdrawals, inquiries, and transfers 
> Supermarket payments with debit or credit cards 
> Buying merchandise over the Internet 


For example, inside a bank branch office or using the Internet bank, customers are using 
online services when checking an account balance or directing fund balances. 


So an online system has many of the characteristics of an operating system: 


It manages and dispatches tasks 

It controls user access authority (CRUD) to system resources 
It manages real memory 

It manages and controls simultaneous access to data files 

It provides device independence 


vvvvy 


11.2.3 Two-phase Commit 
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The two-phase commit protocol is a set of actions used to make sure that an application 
program either makes all changes to the resources represented by a single unit of 
recovery (UR) or makes no changes at all. The protocol verifies that either all changes or 
no changes are applied even if one of the elements, like the application, the system, or the 
resource manager fails. The protocol allows for restart and recovery processing to take 
place after system or subsystem failure. 


The two-phase commit protocol is initiated when the application is ready to commit or 
back out its changes. At this point, the coordinating recovery manager, also called the 
syncpoint manager, gives each resource manager participating in the unit of recovery an 
opportunity to vote on whether its part of the UR is in a consistent state and can be 
committed. If all participants vote "YES", the recovery manager instructs all the resource 
managers to commit the changes. If any vote "NO", the recovery manager instructs them 
to back out the changes. This process is usually represented as two phases. 


In phase 1, the application program issues the syncpoint or roll back request to the 
syncpoint coordinator. The coordinator issues a PREPARE command to send the initial 
syncpoint flow to all the UR agent resource managers. In response to the PREPARE 
command, each resource manager involved in the transaction will reply to the syncpoint 
coordinator stating whether it is ready to commit or not. 


When the syncpoint coordinator receives all the responses back from all its agents, phase 
2 is initiated. In this phase the syncpoint coordinator issues the commit or roll back 
command based on the previous responses. If any of the agents came back with a 
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negative response, the syncpoint initiator will tell al! the syncpoint agents to roll back 
their changes. 


The instant when the coordinator records the fact that it is going to tell all the resource 
managers to either commit or roll back is known as the atomic instant. Regardless of any 
failures after that time, the coordinator will assume that all changes will either be 
committed or rolled back. A syncpoint coordinator will usually log the decision at this 
point. If any of the participants abend after the atomic instant, the abending resource 
manager must work with the syncpoint coordinator when it restarts to complete any 
commits or roll-backs that were in process at the time of the abend. 


During the first phase of the protocol, the agents do not know whether the syncpoint 
coordinator will commit or roll back the changes until the syncpoint coordinator has 
collected all responses. This time is known as the indoubt period. The UR is described as 
having a particular state depending on what stage it is at in the two phase commit 
process: 


> Before a UR makes any changes to a resource it is described as being /n-reset. 
> While it is requesting changes to resources it is described as being /n-flight. 
> Once a commit request has been made (Phase 1) it is described as being /n-prepare. 


> Once the syncpoint manager has made a decision to commit (phase 2 of the 
two-phase commit process) it is In-commit. 


> Ifthe syncpoint manager decides to backout it is In-backout. 


Figure 11-3 on page 11-8 is a brief diagram illustrating two-phase commit: 
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INITIAOR Agent of A Agent of B 
Update local resources Update local resources Update local resources 
Phase 1 Prepare Receive 


Prepare Receive 


Commit 
SYNCPOINT 


Commit 


SYNCPOINT 


SYNCPOINT 
Phase 2 











Figure 11-3 Two-phase commit 


Two-phase commit and legacy resource managers 

The traditional resource managers on z/OS (CICS, IMS and DB2) all support two-phase 
commit protocols. CICS, for example, supports full two-phase commit with IMS and 
DB2, and supports two phase commit across distributed CICS systems. Why, you might 
ask, do we need a new syncpoint manager on z/OS? The problem is there are many 
restrictions imposed on application developers attempting to develop new applications 
that require updates in many different resource managers, perhaps across a number of 
systems. A lot of these new applications use technologies like DB2 stored procedures, 
Enterprise Java Beans and use client attachment facilities of CICS or IMS that do not 
support two-phase commit. If any of these resource managers are used by an application 
to update resources, it is not possible to have a global coordinator for the syncpoint. 


The lack of a global syncpoint coordinator might have influenced some application 
design for the following reasons: 


> The application would not have been capable of having complex and/or distributed 
transactions 1f all the resource managers were not participating in the two-phase 
commit protocol. 


> It could not have been designed as a single application (or unit of recovery) across 
multiple systems (except for CICS). 


> The application had to program around these limitations. 
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> It could have limited the choice of where to put the business data in order to ensure 
that all the data could be committed in a single unit of recovery. 


> It could have affected the recoverability of the protected resources and/or their 
integrity in case of a failure of one of the components since there WebSphere 
Application Server no way to either commit or roll back all the updates. 


11.3 Databases 


This chapter gives an overview of basic database (DB) concepts, what they are used for, 
what the advantages are. There are a lot of databases, but we limit the scope to the two 
which are most used on mainframes: hierachical and relational databases. 


11.3.1 What is a database? 


A database provides for the storing and control of business data, independent from (but 
not separate from the processing requirements of) one or more applications. If properly 
designed and implemented, the database should provide a single consistent view of the 
business data, that can be centrally controlled and managed. 


One way of describing a logical view of this collection of data is to use an 
entity/relationship model. The database will record details (attributes) of particular items 
(entities) and the relationships between the different types of entities. For example, for 
the stock control area of an application, you would have Parts, Purchase Orders, 
Customers, Customer Orders (entities). Each entity would have attributes, the PART 
would have a Part No, Name, Unit Price, Unit Quantity, etc. These entities would also 
have relationships between them; a Customer would be related to orders he had placed, 
these would be related to the part that had been ordered, and so on Figure 11-4 on 
page 11-10 illustrates an entity relationship mode. 
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Figure 11-4 Entities, attributes and relationships 


A database management system (DBMS), such as the IMS Database Manager 
component, or the DB2 product, provide a method of storing and using the business data 


in the database. 


11.3.2 Why use a database? 
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When computer systems were first developed, the data was stored on individual files, 
unique to an application or even a small part of an individual application. But a properly 
designed and implemented DBMS provides many advantages over a flat file PDS system: 


1. It reduces the application programming effort 


2. It manages more efficiently the data creation, modification, and access than a non - 
DBMS system. A DBMS easily allows for modifications (additions, rearrangement, 
deletion) of data elements than flat files. As you know, if new data elements need to 
be added to the file, then all applications that use that file must be rewritten, even 
those that do not use the new data element.This needs not happen when using a 
DBMS. Although many programmers have resorted to ‘tricks’ to minimize this 
application programming rewrite task, it still needs effort. 
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It provides a greater level of security and confidentiality of the data than a flat file 
system. Specifically, when accessing a logical record in a flat file, the application can 
see ALL data elements - including any confidential or privileged data. To minimize 
this, many customers have resorted to putting the sensitive data into a separately 
managed file, and linking the two as necessary. This may cause data consistency 
issues. 


With a DBMS, the sensitive data can be isolated in a separate segment (in IMS/DB) 
of View (in DB2) that prevents unauthorized applications from seeing this data. But 
these data elements are an integral part of the logical record! 


The same details might be stored in several different places, for example the details of a 
customer might be in both the ordering and invoicing application. This caused a number 
of problems: 


> 


> 


As the details were stored and processed independently, details that were supposed to 
be the same, for example a customers name and address, might be inconsistent in the 
various different applications. 


When common data had to be changed, it had to be changed in several places, causing 
a high workload. If any copies of the data were missed, it resulted in the problems 
detailed in the previous point. 


There was no central point of control for the data, to ensure it was secure, both from 
loss and from unauthorized access 


The duplication of the data wasted space on storage media. 


The use of a database management system like IMS Database Manager component or 
like DB2, to implement the database also provides additional advantages. The DBMS: 


> 


allows multiple tasks to access and update the data simultaneously while preserving 
database integrity. This is particularly important where large numbers of users are 
accessing the data via an online application. 


will provide facilities for the application to update multiple database records and 
ensure the application data in the different records remains consistent even if an 
application failure occurs. 


is able to put confidential or sensitive data in a separate segment (in IMS) or table (in 
DB2). While in a PDS or VSAM flat file, the application program gets access to 
every data element in the logical record; some of these might contain data that should 
be restricted. 


provides utilities that control and implement backup and recovery of the data, 
preventing loss of vital business data. 


will provide utilities to monitor and tune the access to the data. 


is able to change the structure of the logical record (by adding or moving data fields). 
Such changes usually require that every application that accesses the VSAM or PDS 
file must be re-assembled or re-compiled, even if they do not need the added or 
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changed fields. A properly designed data base insulates the application programmer 
from such changes. 


The use of a database and database management system will not, in itself, produce the 
advantages detailed above. It also requires the proper design and administration of the 
databases, and development of the applications. 


11.3.3 The database administrator role 


The centralization of data and control of access to this data is inherent to a database 
management system. One of the advantages of this centralization is the availability of 
consistent data to more than one application. As a consequence, this dictates tighter 
control of that data and its usage. Responsibility for an accurate implementation of 
control lies with the database administrator (DBA) function. Indeed, to gain the full 
benefits of using a centralized database, you must have a central point of control for it. 
Because the actual implementation of the DBA function is dependent on a companies 
organization, we limit ourselves to a discussion of the roles and responsibilities of a 
DBA. The group fulfilling the DBA role will need experience in both application and 
systems programming. 


DBA roles and responsibilities in a typical installation might be as follows: 


> The DBA provides standards for, and controls the administration of, the databases 
and their use. 


> The DBA provides guidance, review and approval of database design. 

> The DBA determines the rules of access to the data and monitors their security. 

> The DBA controls the database integrity and availability, monitoring the necessary 
activities for reorganization backup/recovery. 


> The DBA is not responsible for the actual content of databases, this is the 
responsibility of the user. Rather, the DBA enforces procedures for accurate, 
complete, and timely update of the databases. 


> The DBA approves the operation of new programs with existing production 
databases, based on results of testing with test data. 


In general, the DBA is responsible for the maintenance of current information about the 
data in the database. Initially, this responsibility might be carried out using a manual 
approach. But it can be expected to grow to a scope and complexity sufficient to justify, 
or necessitate, the use of a data dictionary program. 


11.3.4 The database design process 
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The process of database design, in its simplest form, can be described as follows: The 
structuring of the data elements for the various applications, in such an order that: 
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> Each data element is readily available by the various applications, now and in the 
foreseeable future. 


> The data elements are efficiently stored. 


> Controlled access is enforced for those data elements with specific security 
requirements. 


Database design is an area in which a number of different models for databases have been 
developed over the years (such as hierarchical, relational or object) so that there is no 
consistent vocabulary for describing the concepts involved. 


Entities 
A database contains information about entities. An entity is something that: 


> Can be uniquely defined 
> We may collect substantial information about, now or in the future 


In practice, this definition is limited to the context of the applications and/or business 
under consideration. Examples of entities are: parts, projects, orders, customers, trucks, 
etc. It should be clear that defining entities is a major step in the database design process. 
The information we store in databases about entities is described by data attributes. 


Data attributes 


A data attribute is a unit of information that specifies a fact about an entity. For example, 
suppose the entity is a part. Name=Washer, Color=Green and Weight=143 are three facts 
about that part. Thus these are three data attributes. A data attribute has a name and a 
value. A data attribute name tells the kind of fact being recorded; the value is the fact 
itself. In the above example, Name, Color, and Weight are data attribute names; while 
Washer, Green and 143 are values. A value must be associated with a name to have a 
meaning. 


An occurrence is the value of a data attribute for a particular entity. An attribute is always 
dependent on an entity. It has no meaning by itself. Depending on its usage an entity can 
be described by one single data attribute or more. Ideally, an entity should be uniquely 
defined by one single data attribute, for example, the order number of an order. Such a 
data attribute is called the key of the entity. The key serves as the identification of a 
particular entity occurrence, and is a special attribute of the entity. Keys are not always 
unique. In such cases, entities with equal key values are called synonyms. For instance, 
the full name of a person is generally not a unique identification. In such cases we have to 
rely on other attributes such as full address, birthday or an arbitrary sequence number. A 
more common method is to define a new attribute, which serves as the unique key, for 
example, employee number. 


Entity relationships 


The entities identified will also have connections between them, relationships. For 
example, an order will be for a number of parts. Again these relationships only have 
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meaning within the context of the application and business. These relationships can be 
one to one (that is, one occurrence of an entity relates to a single occurrence of another 
entity), one to many (one occurrence of an entity relates to many occurrences of another 
entity) or many to many (many occurrences of one entity have a relationship with many 
occurrences of another entity). 


Relationships can also be recursive, an entity can have a relationship with other 
occurrences of the same entity. For example a part, say a fastener, may consist of several 
other parts, bolt, nut, washer. 


Application functions 

Data itself is not the ultimate goal of a database management system. It is the application 
processing performed on the data which is important. The best way to represent that 
processing is to take the smallest application unit representing a user interacting with the 
database. For example, one single order, one part inventory status. In the following 
chapters we will call this an application function. 


Functions are processed by application programs. In a batch system, large numbers of 
functions are accumulated into a single program (that is, all orders of a day), then 
processed against the database with a single scheduling of the desired application 
program. In the online system, just one or two functions may be grouped together into a 
single program to provide one iteration with a user. Although functions are always 
distinguishable, even in batch, some people prefer to talk about programs rather than 
functions. But, especially in a DB environment, a clear understanding of functions is 
mandatory for good design. Once you have identified the functional requirements of the 
application, you can decide how to best implement them as programs using CICS or 
IMS. The function is, in some way, the individual usage of the application by a particular 
user. As such, it is the focal point of the DB system. 


Access paths 

Each function bears in its input some kind of identification with respect to the entities 
used (for example, the part number when accessing a Parts database). These are referred 
to as the access paths of that function. In general, functions require random access, 
although for performance reasons sequential access is sometimes used. This is 
particularly true if the functions are batched, and if they are numerous, relative to the 
database size, or if information is needed from most database records. For efficient 
random access, each access path should utilize the entities key 


11.3.5 Introduction to database management on z/OS 
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A database system is essentially nothing more than a computerized data-keeping system. 
Users of the system are given facilities to perform several kinds of operations on such a 
system for either manipulation of the data in the database or the management of the 
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database structure itself. Database Management Systems (DBMSs) are categorized 
according to their data structures or types. 


There are several types of databases that can be used on a mainframe to exploit 
z/architecture: inverted list, hierarchic, network or relational. In this topic we limit 
ourselves to hierarchical (IMS) and relational (DB2). 


Hierarchical Database (for example, IMS) 
Relationships and sequence 
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The rules for segments are as follows: 


Root 
One and only one root for each database record 
No higher level segments 
Everything depends on the information in the root 
Other Segment Types 
Up to 254 different segment types (255 including the root) 
Any number of occurrences of each segment type 


Each segment, except the root, is related to one and only one segment at the next 
higher level 


Chapter 11. Overview of online applications and databases on z/OS 11-15 


Chapter11 online app! overview.fm Draft Document for Review December 3, 2004 3:15 pm 


11-16 









Parent of STOCK 
and 
PURCHASE ORDER 


Level 1 (or root) 


Level 2 
Child of Part 


and 
Parent of DETAIL 


PURCHASE 
ORDER 
DETAIL 


Figure 11-5 Hierarchical data structure 
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Each occurrence (or instance) of a parent segment has associated with it 0, 1, 2 or more 
occurrences of a child segment. Each child segment occurrence has associated with it 
one, and only one, occurrence of a parent segment. 


Sometimes it is necessary to distinguish between a segment type, that is, the kind of 
segment; and the segment occurrence, that is, the particular instance of its contents and 
location. 


As shown in Figure 11-5, a parent can have several child segment types. Also, a child 
segment can, at the same time, be a parent segment; that is, it can have children itself. 
The segment with no parent segment, that is, the one at the top, is called the root 
segment. 


Only one segment can appear at the first level in the hierarchy, but multiple segments can 
appear at lower levels in the hierarchy. For example, multiple STOCK and ORDER 
segments can exist for one PART segment. Since each dependent segment in the 
hierarchy has only one parent, or immediate superior segment, the hierarchical data 
structure is sometimes called a tree structure. Each branch of the tree is called a 
hierarchical path. A hierarchical path to a segment contains all consecutive segments 
from the top of the structure down to that segment. 


In Figure 11-5, each PART segment with its dependent STOCK, ORDER, and DETAIL 
segments constitutes a database record. The collection of all these records for all PARTS 
is called a database, that is, the PARTS database. 
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Through the concept of program sensitivity, the structure allows a program to be 
restricted to “seeing” only those segments of information that are relevant to the 
processing being performed. For example, an inventory program could be written to see 
only the PART and STOCK segments of the database record shown in Figure 11-5 on 
page 11-16. The program need not be aware of the existence of the ORDER segment. 


Basic segment types in a hierarchical data structure 


Following is a detailed description of the various segment types and their interrelations 
within the hierarchical data structure. Refer to Figure 11-5 on page 11-16 and Figure 11-6 
on page 11-18 when reading this description. 


> A database record is a root segment and ALL of its dependents. 


> The segment on top of the structure is the root segment. Each root segment normally 
has a key field which serves as the unique identifier of that root segment, and as such, 
of that particular database record (for example, the part number). 


> A dependent segment relies on the segments above it in the hierarchy for its full 
meaning and identification. 


> A parent/child relationship exists between a segment and its immediate dependents. 


> Different occurrences of a particular segment type under the same parent segment are 
twin segments. 


> Segment occurrences of different types under the same parent are sibling segments. 
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Figure 11-6 Segment types and their relationships 


Sequence fields and access paths 


To identify and to provide access to a particular database record and its segments, the DB 
uses sequence fields. Each segment normally has one field denoted as the sequence field. 
The sequence fields in our subset should be unique in value for each occurrence of a 
segment type below its parent occurrence. However, not every segment type need have a 
sequence field defined. Particularly important is the sequence field for the root segment, 
since it serves as the identification for the database record. Normally, the DB provides a 
fast, direct access path to the root segment of the database record based on this sequence 
field. This direct access is extended to lower level segments if the sequence fields of the 
segments along the hierarchical path are specified, too. 


Note: The sequence field is often referred to as the key field, or simply the key. 


The sequential processing order is: 


1. Top-to-bottom 
2. Front-to-back 
3. Left-to-right 


Using Figure 11-6 on page 11-18, an example of an access path would be the PART, 
ORDER and DETAIL segments. It must always start with the root segment. This is the 
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access path as used by the DB. The application program, however, can directly request a 
particular DETAIL segment of a given ORDER of a given PART in one single DB 
request, by specifying a sequence field value for each of the three segment levels. 


Relational DBMS (RDBMS) Theory 


Since the late 1970s, however, databases began to be based on the relational approach. 
The relational database is the predominant approach to data organization in today's 
business world. Dr. E. F. (Ted) Codd developed the relational model at IBM in 1970. 
Codd wanted to establish a theory to base a database system on because up to this time 
databases were not developed using any specific theoretical principles. He created his 
relational model which is based on set theory and table data format: rows and columns. 
Functions on the data also produce results in table format. Relationships are developed 
among the various tables through common columns. Therefore, the fundamental basis of 
a relational database (or rule number one) is that it uses table format. 


In 1985, Codd published his twelve rules that define a relational database. His famous 
“Twelve Rules for Relational Databases” was published in two Computerworld articles: 
“Is Your DBMS Really Relational?” on October 14, 1985 and “Does Your DBMS Run 
By the Rules?” on October 21, 1985. These rules were subsequently expanded upon by 
Codd to where they encompass 333 rules. 


These original rules were incorporated by various companies into their own 
interpretation of a relational database. IBM's relational database offering is DB2 or more 
accurately DB2 Universal Database (DB2 UDB), and there is a form of DB2 on what 
IBM considers their four platforms: z/OS, VM, Linux, and OS/400. In addition, IBM has 
acquired another relational database, Informix, which runs in the LUW environment. 
DB2 as implemented on the mainframe will be the focus of the remainder of this chapter. 


Codd’s relational principles 


The following is a brief introduction to some of Codd's relational principles as 
incorporated in DB2. 


> Primary key 


Beyond the number one rule of table format is that a primary key value or unique 
value be present to access the data. Although functions upon table data are meant to 
produce additional table results or several rows, there are times when it is necessary 
to access just one row at a time. Therefore, it is necessary to define a unique defining 
key, or primary key, on the table data. For an employee table, a primary key would be 
the employee number because that would uniquely identify it and allow for updates of 
just one employee's salary. 


As mentioned, Codd's rules were implemented in various ways by different 
companies. Although Codd mandated that a primary key is required, a primary key is 
optional in DB2. There are times when temporary tables are created to hold data for a 
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short time. Since no updates or row access is necessary, there is no use for a primary 
key. DB2 thus makes a primary key optional. 


Referential Integrity 


Hand-in-hand with a primary key is the idea of referential integrity. A primary key 
defines entity or table integrity by making the entries unique. Referential integrity is a 
way of relating data in one table to data in another. For example, the department 
number column of a department table could be defined as a primary key. In the 
employee table, each employee is assigned to a particular department number. It 
would make sense to relate this column to the primary key in the department table 
through what is known as a foreign key dependency. The department number in the 
employee table (foreign key) has a dependency on the department number in the 
department table (primary key). 


If a department were deleted from the DEPT table, you would not want several 
employees to continue to be assigned to that department in the EMP table because the 
department doesn't exist in your company any longer. DB2 allows you, with 
referential integrity defined, to do one of three things based upon your business 
requirements: delete the employees (e.g., a lay off), set the department number to an 
unknown value for reassignment, or restrict or not allow the deletion of the 
department until there are no employees assigned to it. 


SOL 


Codd's twelve rules also call for a language that can be used to define, manipulate, 
and query the data in the database. Codd envisioned an easy-to-use query language 
based on relational set theory. The specific language, SQL (Structured Query 
Language), was originally developed in the research division of IBM and has been 
adopted by other major relational database vendors. SQL is governed by the 
American National Standards Institute/International Standards Organization. All SQL 
is developed according to the SQL99 or SQL3 ANSI/ISO standard which is a large 
compendium of acceptable SQL structures. No one SQL implementation by a 
company is fully compliant with the standards. Most companies implement a smaller 
subset of the standards, but the standards guarantee a similarity among the different 
SQL versions. 


Nulls 


Codd also introduced the idea of a null value for an item in a table. A null value is 
simply an unknown value or the absence of information. It is not a blank or zero 
because these are actually values: a string character can be blank and a numeric value 
can be zero. A null value is often represented as a dash or a series of dashes, 
depending on the tool used to display the data. 


Normalization/Denormalization 


Normalization is a database design process that helps to identify entities (i.e. tables) 
and attributes (i.e. columns) when you first set up your database. There is a logical 
design process which attempts to streamline the entities/attributes, reducing data 
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redundancy and grouping items appropriately. For example, you might want to put 
the name of the department that an employee works for with the EMP entity. 
However, since this information is already carried in the DEPT entity and can be 
gotten from there, it is redundant in the EMP entity. The normalization process would 
help to identify this. 


There are normalization forms that you follow and work through beginning with the 
first and proceeding to the second up to the fifth. They are cumulative. Most design 
processes work up to the third normal form and stop there. Here is a brief overview of 
them: 


— The First Normal Form (1NF) addresses the structure of an isolated table; a table 
has all of the key attributes are defined, and there are no repeating groups. All 
attributes are dependent upon the primary key. 


— The Second Normal Form (2NF) address one-to-one relationships; a table is in 
1NF and there are no partial dependencies (no attribute is dependent on just a part 
of the primary key). 


— The Third Normal Form (3NF) address one-to-many relationships; a table is in 
2NF and there are no “transitive” dependencies. A transitive dependency is when 
one non-prime attribute depends upon another non-prime attribute. 


— The Fourth (4NF) and Fifth (SNF) Normal Forms deal with many-to-many 
relationships. 


These Normal Forms form a hierarchy in such a way that a schema in a higher normal 
form automatically fulfills all the criteria for all of the lower Normal Forms. 


As a practical manner to minimize the number of tables, in many DB2 environments, 
they allow some transitive dependencies (they are denormalized); that is, they are in 
“2.5” normal form. 


The Fifth Normal Form is the ultimate normal form with respect to projections and 
joins; it is guaranteed to be free of anomalies that can be eliminated by taking 
projections. For more information, refer to a book on relational database design. 


The physical design process involves identifying the actual physical tables for your 
entities. During this part, you might actually reverse your process and denormalize 
some of your data. Sometimes having the same data in more than one entity makes 
retrieving data faster. It is a question of weighing the benefits of faster retrieval 
against additional storage costs of the redundant data and the update of that data in 
several places. The denormalistion is usually a hard discussion between the DBA and 
the application designer. 


Data Structures 
> Databases 


A database is a logical grouping of data and contains a set of related table spaces and 
index spaces. Typically a database will contain all the data that is associated with one 
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application or with a group of related applications. You could have a payroll database 
or an inventory database, for example. 


Tables 


Tables are logical structures that are made up of rows and columns. It is important to 
know that rows have no fixed order, so if you retrieve data you may need to sort the 
data. The order of the columns is the order specified when the table was created. At 
the intersection of every column and row is a specific data item called a value, or 
more precisely an atomic value. A table is named with a high level qualifier of the 
owner's user ID followed by the table name, for example, TEST.DEPT or 
PROD.DEPT. There are three types of tables: 


a. A base table that is created and holds persistent data, 
b. A temporary table that stores intermediate SQL results, and 


c. A results table that is returned when you use an SQL statement to query tables. 








DEPTNO DEPTNAME MGRNO ADMRDEPT 


Aoo 
Bo1 PLANNING 000020 AOO 
coi INFORMATION CENTER 000030 Aoo 
Do1 


[Do1 Ss | DEVELOPMENT CENTER ee 





E01 SUPPORT SERVICES 000050 AOO 
MANUFACTURING SYSTEMS 000060 Do1 


D111 
ADMINISTRATION SYSTEMS Do1 
Ee OPERATIONS 000080 E01 
E21 SOFTWARE SUPPORT 000100 E01 

















Figure 11-7 Example of a DB2 sample table (Department table) 
Within a table we use: 


¢ Columns: The ordered set of columns are DEPTNO, DEPTNAME, MGRNO, 
and ADMRDEPT. All the data in a given column must be of the same data 


type 
¢ Row: Each row contains data for a single department. 
¢ Value: At the intersection of a column and row is a value. For example, 


PLANNING is the value of the DEPTNAME column in the row for 
department BO1. 


> Indexes 


An index is an ordered set of pointers to rows of a table. Unlike the rows of a table 
which are not in a specific order, an index must always be maintained in order by 
DB2. An index is used for two purposes: 


a. for performance to retrieve data values more quickly and 
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b. for uniqueness. 


By creating an index on the employee's name, you can retrieve data more quickly for 
one particular employee than by scanning the entire table for that employee. Also, by 
creating a unique index on employee number, DB2 will enforce the uniqueness of 
each value. A unique index is the only way DB2 can enforce uniqueness. 


Creating an index automatically creates the index space, the data set that contains the 
index. 


> Keys 
A key is one or more columns that are identified as such in the creation of a table, 
index, or in the definition of referential integrity. 
— Primary key 
A table can only have one primary key because it defines the entity. There are two 
requirements for a primary key: 
i. it must have a value, i.e. it cannot be null, and 
ii. it must be unique, meaning it must have a unique index defined on it. 
— Unique key 


We already know that a primary key must be unique, but it is possible to have 
more than one unique key in a table. For our EMP table, the employee number is 
defined as the primary key and is therefore unique. If we also had a social security 
value in our table, hopefully that value would be unique. To guarantee this, you 
could create a unique index on the social security column. 


— Foreign key 
A foreign key is a key that is specified in a referential integrity constraint to make 
its existence dependent on a primary or unique key (parent key) in another table. 


The example given mentioned above is that of an employee's work department 
number relating to the primary key defined on the department number in the DEPT 
table. This constraint is part of the definition of the table. 


SQL 

Structured Query Language, better known as SQL, is a high-level language that is used to 
specify what information a user needs without having to know how to retrieve it. The 
database is responsible for developing the access path needed to retrieve the data. SQL 
works at a set level, meaning that it is designed to retrieve one or more rows. Essentially, 
it is used on one or more tables and returns the result as a result table. 


SQL has three categories based on the functionality involved: 


1. DML - data manipulation language used to read and modify data. There are four SQL 
statements to do so: SELECT, UPDATE, INSERT and DELETE. 
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2. DDL - data definition language used to define, change or drop objects. You have tree 
statements for this: CREATE, ALTER and DROP. 


3. DCL - data control language used to grant and revoke authorizations, which has two 
statements: GRANT and REVOKE. You can specify very granular authorities on 
your objects, or there is syntax to provide all the appropriate authorities. 


If you don’t know any SQL, it may be interesting to learn more about it in for example 
the DB2 UDB for z/OS: SOL Reference. 


11.3.6 A database comparison 


Use IMS Hierarchical model when the data structure (not data values) of the data needed 
for an application is relatively static. I.e. a Bill of Material (BOM) database structure 
always has a high level assembly part number, and several levels of components with 
sub-components. 


It usually has a component forecast, cost and pricing data, etc. The structure of the data 
for a BOM application rarely changes, and new data elements (not values) are rarely 
identified. An application normally starts at the top with the assembly part number, and 
goes down to the detail components. 


Both database systems we have just discussed, have the above mentioned benefits (see 
11.3.2, “Why use a database?” on page 11-10), the RDBMS has the additional, 
significant advantage over the hierarchical DB of being non-navigational. 


By navigational, we mean that in a hierarchical DB like IMS, the application programmer 
must know the structure of the database. The program must contain specific logical to 
navigate from the root segment to the desired child segments containing the desired 
attributes or elements. The program must still access and ignore all the intervening 
segments not needed. 


In contrast, in a non-navigational DBMS such as DB2, the application programmer need 
not know the table design. He only needs to know that the desired data element (or 
attribute) exists in the table. The application programmer simply requests the desired data 
elements (which may be in many tables), DB2 determines the most efficient way to 
retrieve them. DB2 may use one the available indexes, or simply do a sequential search. 
The actual access path is of no concern to the application programmer; this is a 
significantly easier programming effort. 


11.4 Summary 


In this chapter we have seen how applications keep on changing, depending on different 
needs of the organization itself, its customers and/or suppliers. Often those changes will 
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be executed via new technologies, but the good working, solid application will remain 
unchanged. 


Interaction with the computer will happen online via the help of a transaction. We do 
have several products to select from (they will be discussed in the next chapters), but 
their principles are the same. 


Data can be stored in flat file, but this usually results in lots of duplication, which may 
result into inconsistent data. Therefor it is better to create central databases, which can be 
accessed (reading and changing) from different places. The handling of consistency, 
security, etc... are done by the database management system; the user/developer does not 
need to worry about it anymore. 








Key terms in this chapter 
Transactional segment Normalization 
Multitasking SQL Multithreading 
root WAP 2-phase-commit 
Database table thread 

DML 














11.5 Discussion questions 


Give some typical BATCH processing actions? 
What transactions do you use? 

Give some business online transactions. 

What is multitasking? 

What is multithreading? 

What are the characteristics of an online system? 
Explain two-phase-commit. 


What are twin segments? 


oe eS Ae SE Se YP 


What is the root? 
10. What are some of Codd's relational principles? 


11. What is the difference between a unique key and a primary key? 
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12. Did Codd develop SQL? 
13. What kind of language is SQL? Is it a programming language? 
14. Give the 3 first normaization forms. 


15. What are some of the responsibilities of a database administrator (DBA)? 
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11.6 Instructor notes 


11.6.1 refer to 11.3.1, “What is a database?” on page 11-9: IMS DB 


IMS DB is a hierarchical database manager providing an organization of business data 
with program and device independence. It has a built-in data share capability. 


It has been developed to provide an environment for applications that require very high 
levels of performance, throughput and availability. The development has been designed 
to make maximum use of the facilities of the z/OS operating system and hardware on 
which it runs. 


IMS is a database subsystem that runs on the mainframe and is a collection of interrelated 
data items organized in a form for easy retrieval. The collection of data is stored in a 
computer system. The retrieval is done by application programs. Each item of data only 
needs to be stored once and can be shared among the programs and users. 


An IMS database is organized as a hierarchy levels of data. Data at lower levels depends 
on data at higher levels for its context and you cannot understand the lower level without 
knowing the higher levels. 


The IMS Database is a group of related database records and each database record is a 
single hierarchy of related segments. A segment is a group of related fields and a field is 
a single piece of data. It can be used as a key for ordering the segments or used as a 
qualifier for searching. The field may only having meaning to the applications that are 
using it. 


11.6.2 refer to 11.3.3, “The database administrator role” on 
page 11-12: another view 


Note that the DBA is NOT responsible for the data, only for the system supporting it. 


The figure below is the one used in the presentation, not in the students material, just to 
have some variation from the bullets. 


Note that in the DB2 chapter there is also a description concerning the DBA, but that is 
mainly to make the link to the system administrator, and their different responsibilities. 
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Figure 11-8 the roles of a DBA 


11.6.3 refer to “Introduction to database management on z/OS” on 


page 11-14 


We don’t talk about OO databases, although they may be used on mainframes, currently 
that is not that common. In case you get questions about it, you can just mention it. We 
did not look for it, but we are sure that you will find some good books on this. The way of 
thinking differs too much from the other databases. 


A good article on the normalization forms can be _ found on: 
http://www-106.ibm.com/developerworks/web/library/wa-dbdsgn2.html 


Note that it is very important for the students to know that in a hierarchical database, you 
have to read throw the complete hierarchy, until you find the segment that you need; the 
reading happens from top to bottom, from front to back and from left to right. It is 
mentioned again in the IMS chapter 


In DB2, mainly for practical reasons of development a number of tables are 
denormalized again. That’s usually discussed between the DBA and analyst of the 
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application. Good common sense should be used (most of the times a performance reason 
is used). 


Also note that VIEWS are not discussed here, because some other RDBMS have another 
interpretation of the use. We do know that within DB2 (mainly in the past) views are 
often used to make a difference between the data responsibilities and the definition itself. 


11.6.4 refer to 11.3.6, “A database comparison” on page 11-24 


The summary gives a small comparison between IMS and DB2. The students will usually 
not get that choice: they will use whatever is available at their site, because most 
mainframe companies have already their products and will continue with that. The major 
changes will be the upgrades of the products. 


11.6.5 refer to 11.5, “Discussion questions” on page 11-25: Answers 


1. Give some typical batch processing actions? 


— money transfers between 2 banks 

— reading a book 

— watching a movie 

— queuing the cashier in the supermarket 

— a day in our live: the alarm goes off, you get up, take a shower, breakfast... 
— making coffee 


2. What transactions do you use? 


— Paying ina shop 
— starting your car 
— getting a boarding card to a fight 


3. Give some business online transactions. 


— getting money “out of the wall” 
— pay your invoices via the internet 


4. What is multitasking? 


Multitasking is essential in any environment in which thousands of users can be 
logged in at the same time. When a multitasking transactional system receives a 
request to run a transaction, it can start a new task that is associated with one instance 
of the execution of the transaction. That is, one execution of a transaction, with a 
particular set of data, usually on behalf of a particular user at a particular terminal. 


5. What is multithreading? 


Multithreading allows a single copy of an application program to be processed by 
several transactions concurrently. 


6. What are the characteristics of an online system? 


Chapter 11. Overview of online applications and databases on z/OS 11-29 


Chapter11 online app! overview.fm Draft Document for Review December 3, 2004 3:15 pm 


11-30 


— many users can access at the same time 
— repetitive actions 

— short interactions 

— data sharing 

— data integrity has to be guaranteed 

— low cost per transactions 


7. Explain two-phase-commit. 
During the first phase of the protocol, the agents do not know whether the syncpoint 
coordinator will commit or roll back the changes until the syncpoint coordinator has 
collected all responses. This time is known as the indoubt period. The UR is 
described as having a particular state depending on what stage it is at in the two phase 
commit process: 
— Before a UR makes any changes to a resource it is described as being /n-reset. 
— While it is requesting changes to resources it is described as being /n-flight. 
— Once a commit request has been made (Phase 1) it is described as being 
In-prepare. 
— Once the syncpoint manager has made a decision to commit (phase 2 of the 
two-phase commit process) it is In-commit. 
— Ifthe syncpoint manager decides to backout it is In-backout. 
8. What are twin segments? 
two or more occurrences of a particular segment type, depending on the same parent 
segment. 
9. What is the root? 
The first segment of a database record, the one without parent, defining the record. 
10. What are some of Codd's relational principles? 
— Primary key (PK) 
— referential integrity 
— a language to define, manipulate and query the data 
— Null values 
— normalization/denormalization 
11. What is the difference between a unique key and a primary key? 
— PK identifies the record uniquely; has to be unique and does not allow null values 
and you can have only | 
— Unique key: also identifies a record unique, but may also allow null values. Each 
PK is also a unique key, not each unique key is PK. You can have several unique 
keys on | table. 
12. Did Codd develop SQL? 
No, IBM did. 
13. What kind of language is SQL? Is it a programming language? 
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No, you can define, manipulate and query data, but you cannot program with it. It just 
supports access to the data 


. Give the 3 first normaization forms. 


The First Normal Form (1NF) addresses the structure of an isolated table; a table 
has all of the key attributes are defined, and there are no repeating groups. All 
attributes are dependent upon the primary key. 

The Second Normal Form (2NF) address one-to-one relationships; a table is in 
1NF and there are no partial dependencies (no attribute is dependent on just a part 
of the primary key). 

The Third Normal Form (3NF) address one-to-many relationships; a table is in 
2NF and there are no “transitive” dependencies. A transitive dependency is when 
one non-prime attribute depends upon another non-prime attribute. 


. What are some of the responsibilities of a database administrator (DBA)? 


The DBA provides standards for, and controls the administration of, the databases 
and their use. 

The DBA provides guidance, review and approval of database design. 

The DBA determines the rules of access to the data and monitors their security. 
The DBA controls the database integrity and availability, monitoring the 
necessary activities for reorganization backup/recovery. 

The DBA is not responsible for the actual content of databases, this is the 
responsibility of the user. Rather, the DBA enforces procedures for accurate, 
complete, and timely update of the databases. 

The DBA approves the operation of new programs with existing production 
databases, based on results of testing with test data. 
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Overview of CICS on 2/OS 
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Objective: During this chapter, you get more familiar with CICS, what it is 
and how it is setup. You will also learn how the program flow should work. 
Next to that you will see how CICS connect to the Web. 


In this chapter, you will learn: 


what CICS is 

what are CICS programs, CICS transactions and CICS tasks 
what conversational and pseudo-conversational programming is 
about CICS and Web-enabling 














12.1 What is CICS? 


CICS stands for Customer Information Control System and is a general-purpose 
transactional system that can support a network of many hundreds or thousands of 
terminals. A large portion of the world's business runs on CICS. 


An CICS application is a collection of related programs that together perform a business 
operation, such as processing a travel request or preparing a company payroll. CICS 
applications execute under CICS control, using CICS services and interfaces to access 
programs and files. 
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CICS is a transaction processing subsystem within the z/OS operating system (although 
this definition might often purists). That means that it provides services for you to run 
applications online, by request, at the same time as many other users are submitting 
requests to run the same applications, using the same files and programs. CICS manages 
the sharing of resources; integrity of data and prioritization of execution, with fast 
response. CICS authorizes users, allocates resources (real memory and cycles,) passes on 
database or VSAM requests by the application to the appropriate DBMS. We could say 
that CICS acts like, and performs many of the same functions of, the z/OS operating 
system. 


CICS applications are traditionally run by submitting a transaction request. Execution of 
the transaction consists of running one or more application programs that implement the 
required function. In CICS documentation you may find CICS application programs 
sometimes simply called programs, and sometimes the term transaction is used to imply 
the processing done by the application programs. 


CICS applications can also take the form of Enterprise Java Beans. You can find out 
more about this form of programming in Java Applications in CICS in the CICS 
Information Center. 


12.1.1 CICS in a Z/OS system 
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Your host operating system, of course, is still the final interface with the computer. CICS 
helps out by separating a particular kind of application program (namely, online 
applications) from others in the system, and handling these programs itself. So, when an 
application program accesses a terminal or any device, it doesn’t communicate directly to 
that. It issues commands to communicate to CICS, which communicates with the needed 
access methods of the operating system. Finally, the access method communicates with 
the terminal or device. 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter12 CICS.fm 


Transactional 


Application 


Program 





Figure 12-1 Transactional system and the operating system 
In order to use specific facilities, CICS must be defined as a z/OS subsystem. 


Each CICS starts in a z/OS system as an address space. There is an option called 
multi-region operation (MRO) that enables the separation of different CICS functions 
into different CICS regions (address spaces); so a specific CICS address space (or more) 
may do the terminal control and will be named terminal owning region (TOR). Another 
possibilities include application-owning region AORs for applications and file-owning 
region FORs for files. 


12.1.2 CICS programs, transactions and tasks 


To develop and run CICS applications, you need to understand the relationship between 
CICS programs, transactions and tasks. These terms are used throughout CICS 
documentation and appear in many commands: 


Transaction: A transaction is a piece of processing initiated by a single request. This 
is usually from an end-user at a terminal, but may also be made from a Web page, 
from a remote workstation program, from an application in another CICS system or 
triggered automatically at a predefined time. The CICS Internet Guide and the CICS 
External Interfaces Guide describe different ways of running CICS transactions. 


A single transaction consists of one or more application programs that, when run, 
carry out the processing needed. 


However, the term transaction is used in CICS to mean both a single event and all 
other transactions of the same type. You describe each transaction type to CICS with 
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a transaction resource definition. This definition gives the transaction type a name 
(the transaction identifier or TRANSID) and tells CICS several things about the work 
to be done; such as what program to invoke first, and what kind of authentication is 
required throughout the execution of the transaction. 


You run a transaction by submitting its TRANSID to CICS. CICS uses the 
information recorded in the TRANSACTION definition to establish the correct 
execution environment, and starts the first program. 


The term transaction is now used extensively in the IT industry to describe a unit of 
recovery or what CICS calls a unit of work. This is typically a complete operation 
that is recoverable; it can be committed or backed out as an entirety as a result of 
programmed command or system failure. In many cases the scope of a CICS 
transaction is also a single unit of work, but you should be aware of the difference in 
meaning when reading non-CICS documentation. 


You will also see the word task used extensively in CICS documentation. This word 
also has a specific meaning in CICS. When CICS receives a request to run a 
transaction, it starts a new task that is associated with this one instance of the 
execution of the transaction. That is, one execution of a transaction, with a particular 
set of data, usually on behalf of a particular user at a particular terminal. You can also 
consider it as analogous to a thread. When the transaction completes, the task is 
terminated. 


12.1.3 Languages and platforms 
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You write a CICS program in much the same way as you write any other program. You 
can use COBOL, OO COBOL, C, C++, Java, PL/I, or assembler language to write CICS 
application programs. Most of the processing logic is expressed in standard language 
statements, but you use CICS commands, or the Java and C++ class libraries to request 
CICS services. 


Most of the times, you use the CICS command level programming interface, “EXEC 
CICS”. This is the case for COBOL, OO COBOL, C, C++, PL/I and assembler programs. 
These commands are defined in detail in the CICS Application Programming Reference. 


Programming in Java with the JCICS class library is described in the Java Applications 
in CICS component of the CICS Information Center. 


Programming in C++ with the CICS C++ classes is described in the CICS C++ OO 
Class Libraries documentation. 


For information about writing Web applications to process HTTP/1.0 requests and 
responses, see the CICS Internet Guide. 
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CICS, today, can run on the different platforms: zSeries (z/OS, OS/390 and VSE), Intel 
servers (Windows NT and Windows 2000), IBM TXSeries for Multiplatforms includes 
the CICS and Encina application servers for AIX, HP-UX, Solaris and Windows systems. 


12.1.4 CICS programming roadmap 


Follow these steps to develop a CICS application that uses the EXEC CICS command 
level programming interface: 


1. Design your application, identifying the CICS resources and services you will use. 
See the chapter on Application Design of the C/CS Application Programming Guide. 


2. Write your program in the language of your choice, including EXEC CICS 
commands to request CICS services. See the CICS Application Programming 
Reference for a list of CICS commands. 


One of the needed components for online transactions is the screen definition; the 
layout of what is displayed on the screen (like a webpage); in CICS we call this a 
MAP (more about this further in this chapter). 


3. Depending on the compiler, you will only need to compile your program, and then 
install it in CICS, or you will need to define translator options for your program and 
then translate and compile your program. See the C/CS Application Programming 
Guide for more details. 


4. Define your program and related transaction to CICS with PROGRAM resource 
definitions and TRANSACTION resource definitions as described in the C/CS 
Resource Definition Guide. 


5. Define any CICS resources that your program uses, such as files, queues or terminals. 


6. Make the resources known to CICS using the CEDA INSTALL command described 
in the CICS Resource Definition Guide. 


12.1.5 Conversational and pseudo-conversational programming 


In CICS, when the programs being executed enter into a conversation with the user, this 
is called a conversational transaction (also see Figure 12-2 on page 12-6). A 
non-conversational transaction (also see Figure 12-3 on page 12-7), by contrast, 
processes one input, responds, and ends (disappears). It never pauses to read a second 
input from the terminal, so there is no real conversation. There is a technique in CICS 
called pseudo-conversational processing, in which a series of non-conversational 
transactions gives the appearance (to the user) of a single conversational transaction. No 
transaction exists during the user waits for input; CICS takes care of reading the input 
when the user gets around to sending it. Look at the following two figures with different 
types of conversation in an example of record update in a banking account. 
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Conversational: pRoauena 
User Menu 
ae Enter account 
puts Function code 
SEND MAP 
Menu RECEIVE MAP 
aay READ FILE UPDATE 
Enter account 1234 _ 
Function code M 
Record Update SEND MAP 
eer Enter account 1234 
Types Name: Smith 
Changes | Amount: $10.00 RECEIVE MAP 


Date: 05/28/04 REWRITE FILE 


Menu SEND MAP 
RETURN 

Enter account 

Function code 


"Update confirmed" 





Figure 12-2 Example of conversational transaction 
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Pseudo-Conversational: 


User 
Types 
Inputs 


User 
Types 
Changes 


Menu 


Enter account 
Function code 


Menu 


Enter account 1234 _ 


Function code M 





Record Update 


Enter account 1234 


Name: Smith 
Amount: $10.00 
Date: 05/28/04 


Menu 


Enter account 1234 
Name: Smith 
Amount: $99.50 
Date: 05/28/04 
"Update Confirmed" 
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= $$$$_<_<_——Q ~~ 


PROGV000 


SEND MAP... 
RETURN TRANSID(V001).... 





PROGV001 
RECEIVE MAP... 
READ FILE... 
SEND MAP... 


RETURN TRANSID 
(V002).... 


PROGV002 
RECEIVE MAP... 


READ FILE UPDATE.... 
REWRITE FILE.... 


SEND MAP... 


RETURN TRANSID (V000)..] 


Figure 12-3 Example of a pseudo-conversational transaction 


More information can be found in the CICS Application Programming Guide. 


12.1.6 CICS programming commands 


The general format of a CICS command is EXECUTE CICS (or EXEC CICS) followed 
by the name of the required command and possibly one or more options. 


You can write many application programs using the CICS command-level interface 
without any knowledge of, or reference to, the fields in the CICS control blocks and 
storage areas. However, you might need to get information that is valid outside the local 
environment of your application program. 
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When you need a CICS system service, for example when reading a record from a file, 
you just include a CICS command in your code. In COBOL, for example, CICS 
commands look like this: 


EXEC CICS function option option ... END-EXEC. 


The “function” is the thing you want to do. Reading a file is READ, writing to a terminal 
is SEND, and so on. 


An “option” is some specification that’s associated with the function. Options are 
expressed as keyboards. For example, the options for the READ command include FILE, 
RIDFLD, UPDATE and others. FILE tells CICS which file you want to read, and is always 
followed by a value indicating or pointing to the file name. RIDFLD (record identification 
field, that is, the key) tells CICS which record and likewise need a value. The UPDATE 
option, on the other hand, simply means that you intend to change the record and doesn’t 
take any value. So, to read with intent to modify, a record from a file known to CICS as 
“ACCTFIL”, using a key that we stored in working storage as “ACCTC”, we did issue a 
command that looks like this: 


Example 12-1 CICS command example 


EXEC CICS 
READ FILE(‘ACCTFIL’) 
RIDFLD(ACCTC) UPDATE . 
END-EXEC. 


You can use the ADDRESS and ASSIGN commands to access such information. For 
programming information about these commands, see the C/CS Application 
Programming Reference manual. When using the ADDRESS and ASSIGN commands, 
various fields can be read but should not be set or used in any other way. This means that 
you should not use any of the CICS fields as arguments in CICS commands, because 
these fields may be altered by the EXEC interface modules. 


12.1.7 How a CICS transaction flows 
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Normally, end users wishing to begin an online session will firstly identify themselves to 
CICS by signing on. Signing on to CICS gives users the authority to invoke certain 
transactions. Once signed-on, they invoke the particular transaction they intend to use. A 
CICS transaction is usually identified by a one-to-four character transaction identifier or 
TRANSID, which is defined in a table that names the initial program to be used for 
processing the transaction. 


Application programs are stored in a library on a direct access storage device (DASD) 
attached to the processor. They can be loaded when the system is started, or simply 
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loaded as required. If a program is in storage and isn’t being used, CICS can release the 
space for other purposes. When the program is next needed, CICS loads a fresh copy of it 
from the library. 


In the time it takes to process one transaction, the system may receive messages from 
several terminals. For each message, CICS loads the application program (if it isn’t 
already loaded), and starts a task to execute it. Thus multiple CICS task can be running 
concurrently. 


Multithreading is a technique that allows a single copy of an application program to be 
processed by several transactions concurrently. For example, one transaction may begin 
to execute an application program (a traveller requests his information). While this 
happens another transaction may then execute the same copy of the application program 
(another traveller requests her information). Compare this with single-threading, which is 
the execution of a program to completion: processing of the program by one transaction 
is completed before another transaction can use it. Multithreading requires that all CICS 
application programs be quasi- reentrant; that is, they must be serially reusable between 
entry and exit points. CICS application programs using the CICS commands obey this 
tule automatically. 


CICS maintains a separate thread of control for each task. When, for example, one task is 
waiting to read a disk file, or to get a response from a terminal, CICS is able to give 
control to another task. Tasks are managed by the CICS task control program. 


CICS manages both multitasking and requests from the task themselves for services (of 
the operating system or of CICS itself). This allows CICS processing to continue while a 
task is waiting for the operating system to complete a request on its behalf. Each 
transaction that is being managed by CICS is given control of the processor when that 
transaction has the highest priority of those that are ready to run. 


While it runs, your application program requests various CICS facilities to handle 
message transmissions between it and the terminal, and to handle any necessary file or 
database accesses. When the application is complete, CICS returns the terminal to a 
standby state. Figure 12-4 on page 12-10 should help you understand what goes on. 
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Operating System 


Terminal System 
Control Services 





Storage 
Mgmt. 





Filévor DB 





Figure 12-4 CICS Transaction Flow (part 1) 


The flow of control during a transaction (code ABCD) is shown by the sequence of 
numbers | to 8. Don’t take this transaction too seriously: we’re only using it to show 
some of the stages than can be involved. The meanings of these eight stages are as 
follows: 


1. Terminal control accepts characters ABCD, typed at the terminal, and puts them in 
working storage. 


2. System services interpret the transaction code ABCD as a call for an application 
program called ABCDOO. If the terminal operator has authority to invoke this program, 
it is either found already in storage or loaded into storage. 


3. The program library into working storage, where ... 
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Figure 12-5 CICS Transaction Flow (part 2) 


4. 






A task is created. Program ABCD00 is given control on its behalf. This particular 
program invokes ... 


Basic mapping support (BMS) and terminal control to send a menu to the terminal, 
allowing the user to specify precisely what information is needed. 


Operating System 





File 
Control 





Program 
ABCD01 mi l=) Co} B) =) 








Figure 12-6 CICS Transaction Flow (part3) 


6. 


BMS and terminal control also handle the user’s next input, returning it to ABCD01 
(the program designated by ABDCO00 to handle the next response from the terminal) 
which then invokes ... 
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7. File control to read the appropriate file for the invocation the terminal user has 
requested. Finally, ABCDO1 invokes ... 


8. BMS and terminal control to format the retrieved data and present it on the terminal. 


12.1.8 CICS Services for Application Programs 
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CICS applications execute under CICS control, using CICS services and interfaces to 
access programs and files. 


Application Programming Interface 

You use the Application Programming Interface, or API to access CICS services from the 
application program. You write a CICS program in much the same way as you write any 
other program. Most of the processed logic is expressed in standard language elements, 
but you can use CICS commands to request CICS services. 


Terminal Control Services 

These services allow a CICS application program to communicate with terminal devices. 
Through these services, information may be sent to a terminal screen and the user input 
may be retrieved from it. It’s not easy to deal with Zerminal Control services in a direct 
way. Basic Mapping Support, or BMS, lets communicate with a terminal with a higher 
language level. It formats your data, and you do not need to know the details of the data 
stream. 


File and Database Control Services 
We may differentiate the following two different CICS data management services: 


1. CICS file control: it offers you access to data sets that are managed by either the 
virtual storage access method (VSAM) or the basic direct access method (BDAM). 
CICS file control let you read, update, add and browse data in VSAM and BDAM 
data sets and delete data from VSAM data sets. 


2. Database control: it lets you access DL/I and DB2 databases. Although CICS has two 
programming interfaces to DL/I, we recommend that you use the higher-level EXEC 
DLI interface. CICS has one interface to DB2 - the EXEC SQL interface, which offer 
powerful statements for manipulating set of tables - thus relieving the application 
program of record-by-record (or segment-by-segment, in the case of DL/I) 
processing. 


Other CICS Services: 


> Task Control: can be used to control the execution of a task. You may suspend a task 
or schedule the use of a resource by a task by making it serially reusable. Also the 
priority assigned to a task may be changed. 
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Program Control: the CICS program control facility governs the flow of control 
between application programs in a CICS system. The name of the application referred 
to in a program control command must have been defined as a program to CICS. You 
can use program control commands to link one of your application programs to 
another, transfer control from one application program to another, with no return to 
the requesting program. 


Temporary Storage (TS) and Transient Data (TD) Control: the CICS temporary 
storage control facility provides the application programmer with the ability to store 
data in temporary storage queues, either in main storage or in auxiliary storage on a 
direct-access storage device. The CICS transient data control facility provides a 
generalized queuing facility to queue (or store) data for subsequent or external 
processing. 


Interval Control: these services provide functions that are related to time. Using 
interval control commands, you can start a task at a specified time or after a specified 
interval, delay the processing of a task, request notification when a specified time has 
expired, among others. 


Storage Control: the CICS storage control facility controls requests for main storage 
to provide intermediate work areas and other main storage needed to process a 
transaction. CICS makes working storage available with each program automatically, 
without any request from the application program, and provides other facilities for 
intermediate storage both within and among tasks. In addition to the working storage 
provided automatically by CICS, however, you can use other CICS commands to get 
and release main storage. 


Dump and Trace Control: the dump control provides a transaction dump when an 
abnormal termination occurs during the execution of an application program. CICS 
trace is a debugging aid for application programmers that produces trace entries of the 
sequence of CICS operations. 


12.1.9 Defining the screens 


As explained before, BMS lets you create the maps that detail the elements on the 
terminal screen. Each screen is defined with BMS macros, which are a form of assembler 
language. When you’ve defined the whole map, you put some job control languages 
(JCL) around it and assemble it. You assemble it twice, in fact. One of the assembles 
produces the physical map. This is stored in the execution libraries, just like a program, 
and CICS uses it when it executes a program using this particular screen. 


The physical map contains the information BMS needs to: 


> 


Build the screen, with all the titles and labels in their proper places and all the proper 
attributes for the various fields. 


Merge the variable data from your program in the proper places on the screen when 
the screen is sent to the terminal. 
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> Extract the variable data for your program when the screen is read. 


The other assembly produces a structure which we call the symbolic description map or 
DSECT. This structure defines all the variable fields (the ones you might read or write in 
your program), so that you can refer to them by name. The data structure gets placed in a 
library along with similar COPY structures like file record layouts, and you simply copy 
them into your program. 


12.1.10 Program control 
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A transaction (task) may execute several programs in the course of completing its work. 


The program definition contains one entry for every program used by any application in 
the CICS system. Each entry holds, among other things, the language in which the 
program is written. The transaction definition has an entry for every transaction identifier 
in the system, and the important information kept about each transaction is the identifier 
and the name of the first program to be executed on behalf of the transaction. 


You can see how these two sets of definitions, transaction and program, work in concert: 


> The user types in a transaction identifier at the terminal (or the previous transaction 
determined it). 


> CICS looks up this identifier in the list of installed transaction definition. 
> This tells CICS which program to invoke first. 


> CICS looks up this program in the list of installed transaction definitions, finds out 
where its is, and loads it if it isn’t already in the main storage. 


> CICS builds the control blocks necessary for this particular combination of 
transaction and terminal, using information from both sets of definitions. For 
programs in command-level COBOL, this includes making a private copy of working 
storage for this particular execution of the program. 


> CICS passes control to the program, which begins running using the control blocks 
for this terminal. This program may pass control to any other program in the list of 
installed program definitions, if necessary, in the course of completing the 
transaction. 


There are two CICS commands for passing control from one program to another. One is 
the LINK command, which is similar to a CALL statement in COBOL. The other is XCTL 
(transfer control) command, which has no COBOL counterpart. When one program links 
another, the first program stays in main storage. When the second (linked-to) program 
finishes and gives up control, the first program resumes at the point after the LINK. The 
linked-to program is considered to be operating at one logical level lower than the 
program that does the linking. 
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..RETURN 
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RETURN 


Figure 12-7 Transferring control between programs (normal returns) 


In contrast, when one program transfers control to another, the first program is 
considered terminated, and the second operates at the same level as the first. When the 
second program finishes, control is returned not to the first program, but to whatever 
program last issued a LINK command. 


Some people like to think of CICS itself as the highest program level in this process, with 
the first program in the transaction as the next level down, and so on. Figure 12-7 may 
help. 


The LINK command looks like this: 
EXEC CICS LINK PROGRAM(pgmname) 
COMMAREA(commarea) LENGTH(length) END-EXEC. 


where pgmname is the name of the program to which you wish to link. Commarea is the 
name of the area containing the data to be passed and/or the area to which results are to 
be returned. COMMAREA interface is also an option to invoke CICS programs. 
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A sound principle of CICS application design is to separate the presentation logic from 
the business logic; communication between the programs is achieved by using the LINK 
command and data is passed between such programs in the COMMAREA. Such a 
modular design provides not only a separation of functions, but also provides for much 
greater flexibility for the web-enablement of existing applications using new presentation 
methods. 


XYZ2 program. 


12.1.11 Defining Resources to CICS 


You supply resource definition information to CICS by using one or more methods, but 
we briefly mention the so called resource definition online (RDO). This method uses the 
CICS-supplied online transactions CEDA, CEDB and CEDC. Definitions are stored in the 
CICS system definition (CSD) file, and are installed into an active CICS system from the 
CSD file. This CSD file is a VSAM data set. There is an offline utility named DFHCSDUP 
that allows you to make changes to definitions in the CSD file by means of a batch job 
submitted offline. CICS control tables contain resource definition records for resources 
that cannot be defined in the CSD. The tables and their resource definitions are created 
by using the CICS macro instructions. After coding the assembler-language macro 
statements for each resource, you have to assemble the set of macro statements and 
link-edit the output to produce a load module. Which methods you use depends on the 
resources you want to define. 


12.1.12 Our online example 
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When we look back to our travel agent example of Appendix 11, “Overview of online 
applications and databases on z/OS”, examples of CICS transactions are: 


> adding, updating and/or deleting employee information 

> adding, updating and/or deleting available cars by rental company 
> getting the number of available cars by rental company 

> updating prices of rental cars 

> adding, updating and/or deleting regular flights by airline 

> getting the number of sold tickets by airline or by destination 


> Figure 12-8 on page 12-17 shows the possibility to calculate the average salary by 
department. So, the department is entered by the user and the transaction calculates 
the average salary. 
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ABCD Average salary by department 


Type a department number and press enter. 
Department number: A02 


Average salary($): 58211.58 





F3: Exit 








Figure 12-8 CICS application user screen 


12.1.13 Defining Resources to CICS 


To run your system, CICS needs information about your system resources, including 
software resources such as programs and data, and hardware resources such as terminals, 
printers and telecommunication links. 


Resource definition is the process by which you tell your CICS system which resources 
to use, what their properties are, and how it can use it. The end product of the process is 
information held internally by CICS. 


Every resource is defined with a set of attributes. They are the properties of the resource, 
telling CICS, for example, whether a file can be updated, what security level should be 
given to a transaction, or the remote systems with which CICS can communicate. 


More information can be found in the CICS System Programming Reference. 


12.1.14 CICS and Web-enabling 


Web-enabled business applications generally consist of four major elements: 


Presentation logic, which uses Web technologies 

Integration logic, which combines business functions into a marketable solution 
Business logic, which implements a line of business function 

Data logic, which maps business entities onto physical data records 


vvvy 
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The presentation logic may consist of HTML pages and associated scripting, Java 
servlets for the dynamic creation of HTML pages, or Java applets that drive the client 
presentation directly. 


Presentation logic and business logic layers: the presentation logic layer contains the 
elements for presenting the information into the user interface. The business logic layer 
contains the elements for performing the business processing, the application of business 
tules. The access to information is not always considered in the business logic layer but 
into a separate one, the data access logic. 


The integration logic is the additional logic which is needed to combine business 
functions into an offering which is attractive and acceptable to the end user, who might 
be a consumer with little knowledge of the company or its products and mode of 
operation. It may also need to represent the flow of a business process (for example, 
booking an all-in trip) which could take an extended period of time to complete. 


The business logic and the data logic usually exist concurrently in the back-end line of 
business applications; those we want to open up to the Web. 


In the following sections, we provide a short introduction to the strategic CICS 
Web-enabling technologies. 


CICS Web support 


CICS Web support (CWS) eliminates the need for a Web server because it provides a set 
of resources with a subset of the HTTP serving functions found in a general-purpose Web 
server. 
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Figure 12-9 CICS Web Support 
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This interface can be used by both 3270 based transactions and applications that provide 
a callable COMMAREA (this is a buffer to pass data between programs). Two different 
configurations can be used to route the HTTP requests into the CICS region. Both 
configurations allow the use of the same facilities in CICS, although the configuration of 
the two options is significantly different. These configurations are as follows: 


> A direct connection from a Web browser to CICS. This uses the facilities of the CICS 
TCP/IP listener to pass the request directly into CICS Web support. 


> Through the HTTP Server for OS/390 using the facilities of the CICS WebServer 
Plugin. This is a CICS supplied Go Webserver Application Programming Interface 
(GWAPI) extension to the HTTP Server for OS/390. It routes requests from the 
HTTP Server into the CICS region using the EXCI communication mechanism. 


CICS transaction server and Java 

The Java language is designed to be portable and architecture-neutral. The bytecode 
generated by compilation is portable, but requires a machine-specific interpreter for 
execution on different platforms. CICS provides this execution environment using a Java 
Virtual Machine (JVM) that is executing under CICS control. 


When Java was first introduced to CICS, a single use JVM was supplied. CICS created a 
JVM to run a single transaction and then destroyed it, this worked but not efficiently. 
Then the 'resettable' serially reusable JVM became available, improving efficiency. A 
short time later, the High Performance Java compiler was offered, creating mainframe 
executable modules, no JVM required, efficiency improved a little more. Now, a 
persistent continuous JVM is available and rivals the efficiency of procedural languages. 


The JVM is started by the CICS Java launcher, which uses a set of options known as a 
JVM profile. A JVM profile determines the characteristics of a JVM, and applications 
specify the JVM profile that they want their assigned JVM to have. In the JVM profiles 
used by CICS, you can specify standard options that are supported in the persistent 
reusable JVM runtime environment, and also some non-standard options that are subject 
to change in future releases of the Java language specification. You can set up several 
JVM profiles that use different options to cater for the needs of different applications. 


JVM profiles are text files stored on Hierarchical File System (HFS) disks, and they list 
the Java launcher options. Each JVM profile references a JVM properties file, which is 
another text file containing the system properties for the JVM. (System properties are key 
name and value pairs that contain basic information about the JVM and its environment, 
such as the operating system in which the application is running.) Among other things, 
the JVM properties file determines the security properties of the JVM. You can edit JVM 
profiles and JVM properties files using any standard text editor. CICS supplies sample 
JVM profiles and JVM properties files to help you get started. 


Reference: CICS Transaction Server for z/OS Information Center - SK3T-6958-02, 
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CICS Transaction Gateway 


The CICS Transaction Gateway (CICS TG) is a set of client and server software 
components that allows a Java application to invoke services in a CICS region. The Java 
application can be an applet, a servlet, an enterprise bean, or any other Java application. 
In contrast to the above technique, this runs under the control of the web server software, 
under z/OS or not. 
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Figure 12-10 CICS Transaction Gateway components 


The CICS Transaction Gateway consists of the following principal components: 


> Gateway daemon: is a long-running process that functions as a server to 
network-attached Java client applications (such as applets or remote applications) by 
listening on a specified TCP/IP port. The CICS TG supports four different CICS TG 
network protocols (TCP, SSL, HTTP, or HTTPS). 


> Client daemon: is an integral part of the CICS Transaction Gateway on all distributed 
platforms. It provides the CICS client-server connectivity. 


> Configuration tool (ctgcfg): is a Java-based graphical user interface (GUI) supplied 
by the CICS TG on all platforms. It is used to configure the Gateway daemon and 
Client daemon properties, which are stored in the CTGINI file. 


> Terminal Servlet: is a supplied Java servlet that allows you to use a Web browser as 
an emulator for a 3270 CICS application. 
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> Java class library with different components such as base classes, EPI support classes 
(that represent CICS terminals, screens, and fields, and simplify the coding required 
for 3270 screen-scraping), EPI beans (that support development of applications from 
a number of visual development environments, such as IBM VisualAge for Java), 
CICS CCF connector classes and J2EE Connector Architecture classes. 


12.2 Summary 


CICS is a transactional processing subsystem. That means that it provides services for 
you to run applications online, by request, at the same time as many other users may be 
submitting requests to run the same applications, using the same files and programs. 
CICS manages the sharing of resources; integrity of data and prioritization of execution, 
with fast response. CICS applications are traditionally run by submitting a transaction 
request. Execution of the transaction consists of running one or more application 
programs that implement the required function. 


You write a CICS program in much the same way as you write any other program. You 
can use COBOL, C, C++, Java, PL/I, or assembler language to write CICS application 
programs. Most of the processing logic is expressed in standard language statements, but 
you use CICS commands. The different CICS commands are grouped according to the 
function they have, terminal interaction, access to files or program linking. 


Most of the CICS resources may de defined and altered in a online way through CICS 
supplied transactions. Other supplied transactions allow us to monitor the CICS system. 


The continued growth of the Internet has caused many corporations to consider the best 
ways to make their legacy systems available to users on the Internet. A small overview of 
the different technologies available for Web-enablement of CICS applications has been 
shown. 
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12.3 Discussion questions 


Describe the main phases in the CICS programming roadmap 
Discuss conversation and pseudo-conversational design. 


How might the meaning of “business transaction” differ from “CICS transaction”? 


Pe ME 


How do you define resources in CICS? 


12.4 Demonstrations 


The instructor will show you how to define a CICS transaction, with its program. Do 
realize that this is a very simple transaction, which is not that common in CICS. 


12.5 Exercises 


The following exercises provide more practice with CICS programming. It may be 
necessary to consult the CICS Application Programming Guide or other manuals. 


Analyze and update the class program 
> Think ina possible use of the COMMAREA. 
> Several simple updates to the class program transaction may be easily done: 
— Include one additional output field in the screen. The maximum value of 
employee commissions could be an example. 


— Create a previous transaction that could be like a main menu; one the options 
would start the current program. 


— Learn about CICS HANDLE CONDITION statement and find out where may be 
used. 


Business Transaction 


Analyze a typical business transaction. Think in different CICS programs and 
transactions that could be needed to accomplish it. Draw a diagram to show the flow of 
the process. 
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12.6 Instructor Notes 


12.6.1 refer to 12.1.9, “Defining the screens” on page 12-13: detailed 
example 


Let’s have a look at different parts of the map definition that correspond to the user 
screen of the class program. The user is requested to enter one department number, and 
the application obtains the average salary of employees working in that department, and 
displays it. 





/ we txid Average salary by department 7 


Type a department number and press enter. 
Department number: Ad1 


Average salary($): 0204250.00 








\ Fae it 


Figure 12-11 CICS application user screen 


Example 12-2 Screen definition (part 1) - map set definition 


TMAPSET DFHMSD TYPE=&SYSPARM, 
LANG=COBOL, 
MODE=INOUT, 
TERM=3270-2, 
CTRL=FREEKB, 
STORAGE=AUTO, 
TIOAPFX=YES 
hae eeindearack map definition (part 2) 
pwtheeeads fields definitions (part 3) 
DFHMSD TYPE=FINAL 
END 


x KK KK OK 
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Example 12-3 Screen definition (part 2) - map definition 


TMAPO1  DFHMDI SIZE=(24,80), X 
LINE=1, X 
COLUMN=1, X 


MAPATTS=COLOR 


Example 12-4 Screen definition (part 3) - fields definition 


DFHMDF POS=(1,1), 
LENGTH=9, 
ATTRB=(NORM, PROT) , 
COLOR=BLUE, 
INITIAL='ABCD txid' 
DFHMDF POS=(1,26), 
LENGTH=28, 
ATTRB=(NORM, PROT) , 
COLOR=GREEN, 
INITIAL='Average salary by department' 
DFHMDF POS=(9,1), 
LENGTH=41, 
ATTRB=(NORM, PROT) , 
INITIAL='Type a department number and press enter.' 
DFHMDF POS=(11,1), 
LENGTH=18, 
ATTRB=(NORM, PROT) , 
COLOR=GREEN, 
INITIAL='Department number: ' 
DPTONO DFHMDF POS=(11,20), 
LENGTH=3, 
ATTRB=(NORM,UNPROT, IC) , 
COLOR=TURQUOISE, 
INITIAL='___' 
DFHMDF POS=(11,24), 
LENGTH=1, 
ATTRB=ASKIP 
DFHMDF POS=(13,1), 
LENGTH=18, 
ATTRB=(NORM, PROT) , 
COLOR=GREEN, 
INITIAL='Average salary($):' 
AVGSAL DFHMDF POS=(13,20), 
LENGTH=11, 
ATTRB=(NORM, PROT) , X 
COLOR=TURQUOISE 
MSGLINE DFHMDF POS=(23,1), X 
LENGTH=78, X 
ATTRB=(BRT, PROT) , X 
COLOR=BLUE 


x KK XK x KK x K KK x xX Ky 


x KK KK 


x KK XK 


x x 
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DFHMDF POS=(23,79), x 
LENGTH=1, x 
ATTRB=(DRK, PROT, FSET), 
INITIAL=' ' 

DFHMDF POS=(24,1), 

LENGTH=7, 

ATTRB= (NORM, PROT) , 
COLOR=RED, 
INITIAL='F3=Exit! 


x KK OK 


The first part corresponds to the map set definition. You can put several maps together 
into a map set and assemble them all together. For efficiency reasons, it’s a good idea to 
put related maps that are generally used in the same transactions in the same map set. In 
our example, only one map is used. When you’ve defined all the maps for a set, you put 
the DFHMSD macro in front of all the others to define the map set. The map set name is 
specified before DFHMSD macro. Also different characteristics such as the mode (for input 
and output) and language (for copying the map structure into the program) are specified. 


The second part provides the map definition and uses DFHMDI macro. The name of the 
map is TMAPO1 and will consists of 24 rows and 80 columns. 


The third part corresponds to the definition of some of the screen fields (not all are 
showed). For each field in the screen you need one DFHMDF macro. The name before the 
macro, if it exists, is the one for the field. You have to name every field that you intend to 
read and write in your program, but don’t name any field that’s is constant. Only the last 
entry, DPTONO, has a name because it corresponds to the screen field where the user is 
entering the department number. The other fields are constants and are titles or user 
instructions. 


Following is the COBOL COPY structure (symbolic description map) that corresponds 
to the previous map definition and in Figure 12-11 on page 12-23, you may see the user 
screen. 


Example 12-5 COBOL COPY structure of the class program map 


01 TMAPOII. 
02 FILLER PIC X(12). 
02 DPTONOL COMP PIC S9(4). 
02 DPTONOF = PICTURE X. 
02 FILLER REDEFINES DPTONOF. 
03 DPTONOA PICTURE X. 
02 DPTONOI PIC X(3). 
02 AVGSALL COMP PIC S9(4). 
02 AVGSALF — PICTURE X. 
02 FILLER REDEFINES AVGSALF. 
03 AVGSALA PICTURE X. 
02 AVGSALI PIC X(11). 
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02 MSGLINEL COMP PIC $9(4). 
02 MSGLINEF PICTURE X. 
02 FILLER REDEFINES MSGLINEF. 
03 MSGLINEA PICTURE X. 
02 MSGLINEI PIC X(78). 
01 TMAPO10 REDEFINES TMAPO1I. 
02 FILLER PIC X(12). 
02 FILLER PICTURE X(3). 
02 DPTONOO PIC X(3). 
02 FILLER PICTURE X(3). 
02 AVGSALO PIC X(11). 
02 FILLER PICTURE X(3). 
02 MSGLINEO PIC X(78). 


Interacting with the terminal 

Now that we’ve defined our maps, we can think about writing them to the terminal. The 
terminal to which we’ll write, of course, is the one that sent the input and thereby 
invoked the transaction. 


The SEND MAP command 
The SEND MAP command writes formatted output to a terminal. It looks like this: 


EXEC CICS SEND MAP(mapname) MAPSET(setname) 


option option ... END-EXEC. 


> mapname: is the name of the map you want to send. In our previous map definitions 
this corresponds to TMAPO1. 


> setname: is the name of the mapset that contains the mapname. See TMAPSET name 
above. 


> option: there are a number of options that you can specify: they affect what’s sent and 
how it is sent. You can use some combinations of them. 
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MAPONLY: means that no data from you program is to be merged into the map; only 
the information in the map is sent. We use it when we send the menu map the first 
time, because we'll have no information to put into it. 


DATAONLY: is the logical opposite to MAPONLY. You use it to modify the variable 
data in a display that’s already been created. Only the data from your program is 
sent to the screen; you can use this option only after you’ve sent the same map 
without using the DATAONLY option. 


ERASE: causes the entire screen to be erased before what you’re sending is shown. 


ERASEUP: in contract to ERASE, causes just the unprotected field on the screen to 
be erased before your output is placed on the screen. It’s most often used in 
preparing to read new data from a map that’s already on the screen. 


ALARM: it causes the audible alarm to be sounded. 
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— Other options are: FRSET, CURSOR, FREEKB, PRINT and FORMFEED. 


In our class program, depending on the PF pressed or if errors occur, different options are 
used. 


The RECEIVE MAP command 


When you want to receive input from a terminal, you use the RECEIVE MAP command, 
which looks like this: 


EXEC CICS RECEIVE MAP(mapname) MAPSET(setname) 
END-EXEC. 


The MAP and MAPSET parameters have exactly the same meaning as for the SEND MAP 
command. 


We’re showing you a form of the RECEIVE MAP command that does not specify where the 
input data is to be placed. This causes CICS to bring the data into a structure whose name 
is the map name suffixed with the letter I, which is assumed to be in the working storage 
of your program. See next example with the RECEIVE MAP command of our class 
program: 


Example 12-6 RECEIVE MAP command in the class program 


EXEC CICS RECEIVE MAP('TMAPO1') 
MAPSET ('TMAPSET') 
INTO(TMAPO1I) 


Accessing Files 


As explained before, both VSAM files and databases may be accessed from a CICS 
program. In this chapter, we’ll cover only VSAM data sets. Access to databases in CICS 
is not different than in other environments. 


Each file used in any application must be defined to CICS and the most important 
information kept for each is the symbolic file name. When an CICS application program 
makes a file request, it always uses the symbolic file name. 


We may differentiate several options when files are accessed: 


> Direct reading: you read a record in the file with the READ command. When reading a 
KSDS, you can identify the record you want uniquely by specifying its full key 
(RIDFLD option), or you can retrieve the first (lowest key) record whose key meets 
certain requirements. Look at Example 12-7 to see how to read a record from a file 
named MASTER into a specified data area: 


Example 12-7 Direct reading of a record 


EXEC CICS READ 


Chapter 12. Overview of CICS on z/OS = 12-27 


Chapter12 CICS.fm Draft Document for Review December 3, 2004 3:15 pm 


INTO (RECORD) 
FILE (‘MASTER’) 
RIDFLD(ACCTNO) 


> Sequential reading (browsing). You start a browse with the STARTBR command, 
identifying a particular record in the same way as for a direct read. This command 
only identifies the starting position for the browse; it does not retrieve a record. The 
READNEXT command reads records sequentially from this starting point. 





> Record update: to update a record, you must first retrieve it using one of the file 
control read commands that specifies the UPDATE option. After modification by the 
application program, the record is written back to the data set using the REWRITE 
command. 


> Record delete: to delete a single record, you may retrieve it for update with a READ 
UPDATE command, and then issue a DELETE command. You have the option of issuing 
a DELETE command specifying the RIDFLD option. 


> Record addition: you must add records to a file with the WRITE command. They must 
always be written from an area specified by the application program. 


Groups & Lists 


Resource definitions held on the CSD are organized into groups and lists: 


Group A collection of related resources on the CSD. Each resource 
that you define must belong to a group. 
List The name of groups that CICS installs at a initial start. Groups 


do not have to belong to lists, and can be defined independently. 


12.6.2 refer to 12.1.13, “Defining Resources to CICS” on page 12-17: 
additional details 
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Managing transactions, programs and files 
Let’s have a look at CEDA transaction and its main commands to manage CICS resources, 
specially transactions, programs and files. 


To access CEDA transaction, you have to enter CEDA at a CICS terminal. The panel shown 
in next figure appears. The cursor is indicated by the symbol ‘ ’. 
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ENTER GME OF THE FOLLOWING 


ADA 
Alter 
APpend 
CHeck 
COpy 
DeFine 


Delete 
DIs play 
Expand 


Install 


USerdef ine 
view 


SYSID*CICA APPLID-MYCICS 


PF 1 HELP 9 MSG 12 CCL 





Figure 12-12 CEDA transaction: initial panel 


This figure shows a list of all the CEDA commands. The CEDB transaction does not support 
the INSTALL command; the CEDC transaction supports only the DISPLAY, EXPAND, and 
VIEW commands. 


The CEDA DEFINE command 


It creates resource definitions. You specify the resource to be added, the group that will 
contain the resource definition being defined and the resource attribute list. 


Example 12-8 Online definition of the class program transaction 


CEDA DEFINE TRANSACTION(ABCD) GROUP(PAZSGROU) PROGRAM(XYZ2) 


This example defines the class program transaction. The COBOL transaction name is 
ABCD, it is defined into PAZSGROU group with XYZ2 as initial program., Figure 12-13 on 
page 12-30, you may see the output of the CEDA transaction. 


You may execute the CEDA transaction step by step. So, after entering CEDA transaction in 
the CICS session (as shown in previous figure), you may enter the DEFINE (DEF) 
command; a list of the possible resources to define is shown; now TRANSACTION (TRANS) 
is chosen. After pressing ENTER you are shown with a panel like the following figure. It 
contains all the attributes of the resource to define: 
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OVERTYPE TO MODIPY CICS RELEASE = 0630 
CEDA DEFine TRANSaction( ABCD ) 
TRANEaction : ABCD 
Group : PAZSGROU 
DEscription «=> TRANSACTION CLASS PROGRAM 
PROGram ==> XYZ2 
TWasize ==> 00000 0-32767 
PROFile ==> DPHCICST 
PArtitionset <=> 
STAtus ==> Enabled Enabled | Disabled 
PRIMedsize : O0000 0-65520 
TASKDATALoc ==> Below Below | Any 
TASKDATAKey <=> User User | Cics 
STOrageclear ==> No No | Yes 
RUnaway ==> System System | 0 | S00-2700000 
SHutdown ==> Disabled Disabled | Enabled 
TSolate ==> Yes Yea | No 
Brexit -=—> 


+ REMOTE ATTRIBUTES 
I New group PAZSGROU created. 
SYSID-PAZS APPLID-SCSCPAZS 


DEPINE SUCCESSPUL TIME: 15.35.14 DATE: 04.209 
PP 1 HELP 2 COM 3 END 6 CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SP 12 CNCL 


Figure 12-13 CEDA DEFINE panel for the class program transaction 


In the same way, you may add the XYZ2 COBOL program to the same group by executing 
the following CEDA transaction: 


Example 12-9 Defining the COBOL example program 


CEDA DEFINE PROGRAM(XYZ2) GROUP(PAZSGROU) LANGUAGE (COBOL) 


We may also use this transaction to define the BMS physical map as a program to CICS. 
See Figure 12-14 on page 12-31 for the definition of the physical map COBOL program. 
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OVERTYPE TO MODIPY CICE RELEASE = 0630 
CEDA DEFine PROGram( TMAPSET 
PROGram : TMAPSET 
Group : PAZSGROU 
DEscription «=> PHISICAL MAP COBOL PROGRAN 
Language ==> CObol CObol | Assembler | Le370d | C | Pli 
RELoad ==> No No Yes 
RESident ==> No No Yea 
USAge ==> Norml Nornal | Transient 
USElpaccpy ==> No No | Yes 
Status ==> Enabled Enabled | Disabled 
RE1 : 00 0-24 | Public 
CEd£ ==> Yes Yea | No 
DAtalocation «=> Below Below | Any 
EXECKey ==> User User | Cics 
Concurrency ==> Quasirent Quasirent | Threadsafe 
REMOTE ATTRIBUTES 
DYnanic ==> No No | Yes 


+ REMOTES ystem <--> 


SYSID-PAZS APPLID-SCSCPAZS 
DEPINE SUCCESSPUL TIME: 15.46.09 DATE: 04.209 
PP 1 HELP 2 COM 3 END 6 CRSR 7 SBH & SFH 9 NSG 10 SB 11 SP 12 CNCL 


Figure 12-14 CEDA DEFINE panel for the physical map COBOL program 
The mapset is also needed to be defined executing the following CEDA transaction: 


Example 12-10 Defining the mapset 


CEDA DEFINE MAPSET(TMAPSET) GROUP (PAZSGROU) 


The CEDA ADD command 


After defining all the resources, the corresponding RDO group may be added to a list. 
The list with which you initialize CICS is a definition of your system (for RDO 
resources). When you introduce changes to your resources, it is useful to create a new 
list, keeping the old list to return to if something goes wrong. Then you can reinitialize 
CICS with the old list, knowing that everything is as it was previously. One CICS system 
can start with different lists. Following is the command to add our PAZSGROU group to a 
list: 


Example 12-11 Adding the group to a list 


CEDA ADD GROUP(PAZSGROU) LIST(PAZSLIST) 
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Other CICS-supplied transactions 
CEMT transaction 


CEMT is the master terminal transaction. You can use it to view the values of CICS system 
definitions and to change such definitions while CICS is running. You can control the 
number of tasks of certain types running at any given time, purge tasks from the system, 
enable or disable transactions or files, start or stop tracing, and so on. 


To view the values of CICS system definitions, use the CEMT INQUIRE command. To 
change the values of system definitions or to change CICS operation, use the CEMT SET, 
CEMT PERFORM 0 CEMT DISCARD command. 


CEDF transaction 

You can use the execution diagnostic facility (EDF) to test an application program online, 
without modifying the program or the program-preparation procedure. The CICS 
execution diagnostic facility is supported by the CICS-supplied transaction, CEDF. 


EDF intercepts the execution of CICS commands in the application program at various 
points, allowing you to see what is happening. Each command is displayed before 
execution, and most are displayed after execution is complete. Screens sent by the 
application program are preserved, so you can converse with the application program 
during testing, just as a user would on a production system. 


CICS-DB2 considerations 


When a CICS application accesses DB2, there are some additional considerations to do: 


> You have to direct the linkage editor to include the CICS-DB2 language interface 
module (DSNCLI). 

> You have to do a CICS definition containing the transaction code and the DB2 plan 
name. Traditionally, these entries were added to a CICS table called Resource Control 
Table (RCT). You may also use the CEDA transaction to do this entry into the CSD file. 
Following is the CEDA transaction to add the XYZE entry for our class program. 
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P 


OVERTYPE TO MODIPY CICS RELEASE = 0630 
CEDA DEFine DB2Entry({ XYZE } 
DB2Entry : XYZE 
Group : PAZSGROU 
DEscription «=» DB2 ENTRY FOR CLASS PROGRAM TRANSACTION 
THREAD SELECTION ATTRIBUTES 
TRansid ==> ABCD 
THREAD OPERATION ATTRIBUTES 
ACcountrec ==> None None | TXid | TAsk | Uow 
AUTHId ==> 
AUTHType ==> Userid ra | Opid | Group | Sign | TErm 
TX 
DRollback -=> Yeo Yea | No 
PLAN ==> XYZP 
PLANExitname <=> 
PRIority ==> High High | Equal | Low 
PROtectnun ==> 0000 0-2000 
THREADLimit ==> 0000 0-2000 
THREADWait ==> Pool Pool | Yes | No 
SYSID-PAZS APPLID-SCSCPAZS 
DEPINE SUCCESSPUL TIME: 15.52.13 DATE: 04.209 
P 1 HELP 2 COM 3 END 6 CRSR 7 SBH & SFH 3 NSG 10 SB 11 SP 12 CNCL 


Figure 12-15 CEDA DEFINE panel for the DB2 entry of class program transaction 


12.6.3 Refer to 12.3, “Discussion questions” on page 12-22: 
Discussion answers 


1. Do you miss any other functions in this text? 


The student could quote the error control (you know the existence of HANDLE 
CONDITION command) or printing (CICS and non-CICS printers, use of transient 
data for printing). 


2. Describe the main phases in the CICS programming roadmap 


a. 


f. 


Design your application, identifying the CICS resources and services you will 
use. See the chapter on Application Design of the CICS Application Programming 
Guide. 

Write your program in the language of your choice, including EXEC CICS 
commands to request CICS services. See the CICS Application Programming 
Reference for a list of CICS commands. 

Depending on the compiler, you will only need to compile your program, and then 
install it in CICS, or you will need to define translator options for your program 
and then translate and compile your program. See the CICS Application 
Programming Guide for more details. 

Define your program and related transaction to CICS with PROGRAM resource 
definitions and TRANSACTION resource definitions as described in the C/CS 
Resource Definition Guide. 

Define any CICS resources that your program uses, such as files, queues or 
terminals. 

Make the resources known to CICS using the CEDA INSTALL 


3. Discuss about conversation and pseudo-conversational design. 
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See chapter 11 (Application Design) in the CICS Application Programming Guide 
which contains an interesting section about this. Here is mainly to recapitulate. 


4. What could be the meaning of “business transaction” compared to “CICS 
transaction’? 


A business transaction is an self-contained business operation, for instance buying a 
theatre ticket. Some business transactions may involves several CICS transactions. 


5. How do you define resources in CICS? 


You supply resource definition information to CICS by using one or more methods, 
but we briefly mention the so called resource definition online (RDO). This method 
uses the CICS-supplied online transactions CEDA, CEDB and CEDC. Definitions are 
stored in the CICS system definition (CSD) file, and are installed into an active CICS 
system from the CSD file. This CSD file is a VSAM data set. There is an offline 
utility named DFHCSDUP that allows you to make changes to definitions in the CSD 
file by means of a batch job submitted offline. CICS control tables contain resource 
definition records for resources that cannot be defined in the CSD. The tables and 
their resource definitions are created by using the CICS macro instructions. After 
coding the assembler-language macro statements for each resource, you have to 
assemble the set of macro statements and link-edit the output to produce a load 
module. Which methods you use depends on the resources you want to define. 


Additional topics: 


1. It could be interesting to discuss about the current huge development done in CICS 
and the different ways of exploiting for new (web) applications. 


Most of the current business logic continues being valid for exploiting from the web. 
Remember that it’s necessary to separate business from presentation logic in CICS 
programs. 


2. A sample demo of CEDF transaction with ABCD user transaction could be 
interesting. 


ABCD transaction is very simple. EDF only intercepts it at the following points, 
allowing you to interact with it: program initiation, start of the execution of SEND 
and RECEIVE CICS commands, end of the execution of both commands and 
program termination. 


12.6.4 refer to 12.4, “Demonstrations” on page 12-22:What to do? 
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Because they do not learn how to write a program, it is hard to let them do some 
exercises. To give them an idea on how it works, you can do a demonstration on the 
whole thing. 


If you wish, you could let the students do the same thing as you, using another group and 
another transaction name. But we do not think that it would be useful. 
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Note that you do need an connection to DB2... 


The map and its assembling and link-editing; the program and its compile-link and go 
(don’t go too deep into the program; the SQL they will get in the DB2 chapter, do the 
bind but don’t explain it yet), the creation of the object in CICS and the transaction itself 
as well. They will think it is not that much work (because you have prepared everything), 
but as you know, it is not always that simple. To make it easier on you, we will guide you 


1. Assembler and link-edit the map (you could do this before the class, to avoid 
unpleasant surprises). This can be done via the execution of 
ZPROF.CLASS.SAMPLIB(MAPASSEM). 


2. Precompile, CICS translation, etc.... of the COBOL program itself, can be done via 
the execution of ZPROF.CLASS.SAMPLIB(CICSDB2P). 


3. Do the CICS definitions as shown in the screens below (note: we did the view 
afterwards, to be sure that everything was working): 


Via CEDA AD GROUP, you can add the group (here it is PAZSGROU). 
Via CEDA DEF TRANS define the transaction: 











¥ trans(ABCD) group (PAZSGROU) 
OBJECT CHARACTERISTICS CICS RELEASE = 0630 

CEDA View TRANSaction( ABCD ) 

TRANSaction : ABCD 

Group : PAZSGROU 

DEscription : TRANSACTION CLASS PROGRAM 

PROGram : XYZ2 

TWasize : 00000 0-32767 

PROFile : DFHCICST 

PArtitionset 

STAtus : Enabled Enabled | Disabled 

PRIMedsize : 00000 0-65520 

TASKDATALoc : Below Below | Any 

TASKDATAKey : User User | Cics 

STOrageclear : No No | Yes 

RUnaway : System System | 6 | 500-2700000 

SHutdown : Disabled Disabled | Enabled 

Isolate : Yes Yes | No 

Brexit : 
+ REMOTE ATTRIBUTES 

SYSID=PAZS APPLID=SCSCPAZS| 

PF 1 HELP 2 COM 3 END 6 CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SF 12 CNCL 








Figure 12-16 


Via CEDA DEF PROG define the program and the mapset: 
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¥ PROG(XYZ2) group (PAZSGROU) 
OBJECT CHARACTERISTICS CICS RELEASE = 0630 
CEDA View PROGram( XYZ2 ) 
PROGram > R¥Z2 
Group : PAZSGROU 
DEscription : CLASS PROGRAM 
Language : CObol CObol | Assembler | Le37@ | c | Pli 
RELoad : No No | Yes 
RESident « No No | Yes 
USAge : Normal Normal | Transient 
USElpacopy : No No | Yes 
Status : Enabled Enabled | Disabled 
RS1 : 00 @-24 | Public 
CEdf : Yes Yes | No 
DAtalocation : Below Below | Any 
EXECKey : User User | Cics 
COncurrency : Quasirent Quasirent | Threadsafe 
REMOTE ATTRIBUTES 
DYnamic : No No | Yes 
+ REMOTESystem 
SYSID=PAZS APPLID=SCSCPAZS 
PF 1 HELP 2 COM 3 END CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SF 12 CNCL 





Figure 12-17 
























i) PROG(TMAPSET) GROUP (PAZSGROU) 
OBJECT CHARACTERISTICS CICS RELEASE = 0630 
CEDA View PROGram( TMAPSET ) 
PROGram : TMAPSET 
Group : PAZSGROU 
DEscription : PHYSICAL MAP COBOL PROGRAM 
Language : CObol CObol | Assembler | Le370 | C | Pli 
RELoad : No No | Yes 
RESident : No No | Yes 
USAge : Normal Normal | Transient 
USElpacopy : No No | Yes 
Status : Enabled Enabled | Disabled 
RSI : 00 0-24 | Public 
CEdf : Yes Yes | No 
DAtalocation : Below Below | Any 
EXECKey : User User | Cics 
COncurrency : Quasirent Quasirent | Threadsafe 
REMOTE ATTRIBUTES 
DYnamic : No No | Yes 
+ REMOTESystem 
SYSID=PAZS APPLID=SCSCPAZS 
PF 1 HELP 2 COM 3 END 6 CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SF 12 CNCL 











Figure 12-18 


The mapset itself also needs to be defined, this can be done via CEDA DEF Mapset 
(TMAPSET) group (PAZSGROU): 
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ij Napset (Tmapset) group (pazsgrou) 


OBJECT CHARACTERISTICS CICS RELEASE = 0630 
CEDA View Mapset( TMAPSET ) 

Mapset : TMAPSET 

Group : PAZSGROU 

Description 

REsident : No No | Yes 

USAge : Normal Normal | Transient 

USElpacopy : No No | Yes 

Status : Enabled Enabled | Disabled 

RSI : 00 0-24 | Public 


SYSID=PAZS APPLID=SCSCPAZS| 


PF 1 HELP 2 COM 3 END 6 CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SF 12 CNCL 








Figure 12-19 the mapset 


You also need to define the DB2Entry via CEDA DEF DB2ENTRY: 








v db2entry(XYZeE). group (pazsgrou) 


OBJECT CHARACTERISTICS CICS RELEASE = 0636 
CEDA View DB2Entry( XYZE J 
DB2Entry : KYZE 
Group : PAZSGROU 
DEscription : DB2 ENTRY FOR CLASS PROGRAM TRANSACTION 
THREAD SELECTION ATTRIBUTES 
TRansid : ABCD 
THREAD OPERATION ATTRIBUTES 
ACcountrec : None None | TXid | TAsk | Uow 
AUTHId : 
AUTHType : Userid Userid | Opid | Group | Sign | TErm 
TX 
DRollback : Yes Yes | No 
PLAN > XYZP 
PLANExitname 
PRIority : High High | Equal | Low 
PROtectnum : 9000 60-2000 
THREADLimit : 9000 68-2000 
THREADWait : Pool Pool | Yes | No 


SYSID=PAZS APPLID=SCSCPAZS 





PF 1 HELP 2 COM 3 END 6 CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SF 12 CNCL 
Figure 12-20 DB2entry 
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If you enquire all defined objects for group PAZSGROU, via CEDA DI you should 
get this: 





ENTER COMMANDS 


NAME TYPE GROUP DATE TIME 

TMAPSET MAPSET PAZSGROU _ 04.218 08.53.06 
TMAPSET PROGRAM PAZSGROU 04.209 15.46.08 
XYZ2 PROGRAM PAZSGROU 04.209 15.42.16 
ABCD TRANSACTION PAZSGROU 04.209 15.35.13 
XYZE DB2ENTRY PAZSGROU 04.209 15.52.13 


SYSID=PAZS APPLID=SCSCPAZS 
RESULTS: 1 TO 5 OF 5 TIME: 16.52.41 DATE: 04.295 
Pr 1 HELP 3 END 4 TOP 5 BOT 6 CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SF 12 CNCL 











Figure 12-21 


4. Start the transaction ABCD. Valid departments are A00, D11, D21.,... 


It may be a good idea to show them also that they need to refresh the programs (and 
maps) if they change it as well. The usually happens via CEMT S PROG(XYZ2). Here are 
the two screens. One before the newcopy (with the ‘new’) and one after: 


S PROG(XYZ2) 
STATUS: RESULTS - OVERTYPE MODIFY 


Prog(XYZ2 ) Leng(6006007792) Cob Pro Ena Pri new Ced 
Res(000) Use(9000000022) Bel Uex Ful Qua 


S PROG(XYZ2) _ L J. 
STATUS: RESULTS - OVERTYPE TOAWODIFY 


Prog(XYZ2 ) Leng(0000007832) Cob Pro Ena Pri Ced NORMAL 
Res(000) Use(0900000022) Bel Uex Ful Qua 



































Figure 12-22 
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The changes that were done are in the program XYZ2, they remove the leading zeros in 
front of the salary (an easy way to see that this is the new version). 


12.6.5 refer to 12.5, “Exercises” on page 12-22: Exercises comment 


The following exercises provide more practice with CICS programming. It may be 
necessary to consult the CICS Application Programming Guide or other manuals. 


Analyze and update the class program 
> Think ina possible use of the COMMAREA. 


Think in passing data between programs called with LINK or XCTL. A generic 
program for error processing may be developed; all the invocations to it may be done 
passing the required error data through the COMMAREA. Also the COMMAREA 
option of the return command is designed for passing data between successive 
transactions in a pseudo-conversational sequence; the state of a resource may be 
passed by the first transaction through COMMAREA in order to be compared to the 
its current state by the second transaction; it may be necessary to know if this has 
changed since the last interaction before allowing an update. In web applications, the 
business logic in a CICS application can be invoked using the COMMAREA 
interface. 


> Several simple updates to the class program transaction may be easily done: 
— Include one additional output field in the screen. The maximum value of 
employee commissions could be an example. 


A new field has to be defined in the map source; perhaps some literals have also to 
be changed. Assemble the map and generate the new copy file. Modify the 
program to have another column in the SQL statement and move its content after 
retrieval to the corresponding new output field in the map. Execute the 
preparation job for the user program. New copies for program and map are 
required in the CICS session. 


— Create a previous transaction that could be like a main menu; one the options 
would start the current program. 


Only two variable fields are required in the map for this transaction, the option 
field and the message line. Only one option has to be initially included, the one for 
the current ABCD transaction. The same mapset may be used to include the new 
map. ABCD transaction has to be modified to do the RETURN TRANSID to the 
new transaction. Only the following resources has to be added to the CICS 
system: the new transaction and programs (user program and map). 


— Learn about CICS HANDLE CONDITION statement and find out where may be 
used. 
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A good exercise could be to add error control for the RECEIVE CICS command. 
The MAPFAIL condition occurs when no usable data is transmitted from the 
terminal after a RECEIVE command. 


Business Transaction 


Analyze a typical business transaction. Think in different CICS programs and 
transactions that could be needed to accomplish it. Draw a diagram to show the flow of 
the process. 


The example that is developed through the manual CICS Application Programming 
Primer could be appropriate. A department store with credit customers keeps a master 
file of its customers’ accounts. The application performs the following actions: display 
customer account records, add new account records, modify or delete existing account 
records, print a single copy of a customer account record, access records by name. 
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Overview of IMS on 2/OS 








> 


vvvy 








Objective: There is not only CICS in the field, some (mainly financial) 
companies choose IMS. This chapter should help you to understand the 
principles of IMS better. 


In this chapter, you will learn: 


what the IMS components are 

the structure of the IMS DB Subsystem 
how databases are used by IMS 
application programming in IMS 

IMS and the World Wide Web 











13.1 What is IMS? 


Information Management System (IMS) consists of three components: the Transaction 
Manager (TM), the Database Manager (DB), and a set of system services that provide 
common services to the other two components. 


As IMS has developed, new interfaces have been added to meet new business 
requirements. It is now possible to access IMS resources using a number of interfaces to 
the IMS components. 
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Figure 13-1 Overview of the IMS product 


You write a IMS program in much the same way as you write any other program. You 
can use COBOL, OO COBOL, C, C++, Java, PL/I, or assembler language to write IMS 
application programs. Further information on programming in Java can be found in the 
IMS Java Guide and Reference. 


IMS Transaction Manager 

The IMS Transaction Manager provides users of a network with access to applications 
running under IMS. The users can be people at terminals or workstations, or other 
application programs, either on the same z/OS system, on other z/OS systems, or on other 
non-z/OS platforms. 


A transaction is a setup of input data that triggers the execution of a specific business 
application program. The message is destined for an application program and the return 
of any results is considered one transaction. 


IMS Database Manager 
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The IMS Database Manager provides a central point of control and access for the data 
that is processed by IMS applications. The Database Manager component of IMS 
supports databases using the IMS hierarchical database model. It provides access to these 
databases from applications running under the IMS Transaction Manager, the CICS 
transaction monitor (now known as Transaction Server for z/OS), and z/OS batch jobs. 


It provides facilities for securing (backup/recovery) and maintaining the databases. It 
allows multiple tasks (batch and/or online) to access and update the data, while retaining 
the integrity of that data. It also provides facilities for tuning the databases by 
reorganizing and restructuring them. 


The IMS databases are organized internally using a number of IMS database organization 
access methods. The database data is stored on disk storage using the normal operating 
system access methods. 


IMS System Services 


There are a number of functions that are common to both the Database Manager and 
Transaction Manager: 


> Restart and recovery of the IMS subsystems following failures. 
> Security: controlling access to IMS resources. 


> Managing the application programs: dispatching work, loading application programs, 
providing locking services. 


> Providing diagnostic and performance information. 
> Providing facilities for the operation of the IMS subsystems. 


> Providing an interface to the other OS/390 subsystems that the IMS applications 
interface with. 


13.1.1 IMS in a Z/OS system 


IMS runs on zSeries and earlier forms of the S/390 architecture or compatible 
mainframes, and on z/OS and earlier forms of the operating system. 


An IMS subsystem runs in several address spaces in a z/OS system. There is one 
controlling address space and several dependent address spaces providing IMS services 
and running IMS application programs. 


For historical reasons, some documents describing IMS use the term region to describe a 
z/OS address space, for example, IMS Control Region. In this book we have used the 
term region wherever this is in common usage. You can take the term region as being the 
same as a z/OS address space. 
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IMS is designed to make the best use of the features of the OS/390 operating system. 
This includes: 


1. 


Running in multiple address spaces - IMS subsystems (except for IMS/DB batch 
applications and utilities) normally consist of a control region address space, 
dependent address spaces providing system services, and dependent address spaces 
for application programs. 


Runs multiple tasks in each address space: IMS, particularly in the control regions, 
creates multiple z/OS subtasks for the various functions to be performed. This allows 
other IMS subtasks to be dispatched by z/OS while one IMS subtask is waiting for 
system services. 


IMS uses OS/390 cross memory services to communicate between the various 
address spaces making up an IMS subsystem. It also uses the z/OS Common System 
Area (CSA) to store IMS control blocks that are frequently accessed by the address 
spaces making up the IMS subsystem. This minimizes the overhead in running in 
multiple address spaces. 


IMS uses the z/OS subsystem feature: IMS dynamically registers itself as an z/OS 
subsystem. It uses this facility to detect when dependent address spaces fail, prevent 
cancellation of dependent address spaces (and to interact with other subsystems like 
DB2 and MQ). 


IMS can make use of a z/OS sysplex. Multiple IMS subsystems can run on the z/OS 
systems making up the sysplex and access the same IMS databases. 


13.1.2 IMS Transaction Manager Messages 
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The network inputs and outputs to IMS Transaction Manager take the form of messages 
that are input/output to/from IMS and the physical terminals or application programs) on 
the network. These messages are processed asynchronously (that is, IMS will not always 
send a reply immediately, or indeed ever, when it receives a message, and unsolicited 
messages may also be sent from IMS). 


The messages can be of four types: 


> 


Transactions: Data in these messages is passed to IMS application programs for 
processing 


Messages to go to other logical destinations, such as network terminals. 
Commands for IMS to process 


Messages for the IMS APPC feature to process. As IMS uses an asynchronous 
protocol for messages, but APPC uses synchronous protocols (that is, it always 
expects a reply when a message is sent), the IMS TM interface for APPC has to 
perform special processing to accommodate this. 
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If IMS is not able to process an input message immediately, or cannot send an output 
message immediately, then the message is stored on a message queue external to the IMS 
system. IMS will not normally delete the message from the message queue until it has 
received confirmation that an application has processed the message, or it has reached its 
destination. 


13.1.3 Functions of the IMS Database Manager 


A database management system (DBMS) provides facilities for business application 
transaction or process to access stored information. The role of a DBMS is to provide the 
following functions: 


Allow access to the data for multiple users from a single copy of the data. 
Control concurrent access to the data so as to maintain integrity for all updates. 
Minimize hardware device and operating systems access method dependencies. 
Reduce data redundancy by maintaining only one copy of the data. 


vvvy 


The IMS Database Manager provides a central point for the control and access to 
application data. IMS provides a full set of utility programs to provide all these functions 
within the IMS product. 


13.1.4 Implementation of IMS Databases 


IMS TM and IMS DB both support multiple forms of enterprise databases, so that varied 
application requirements can be met by exploiting whichever database technology best 
suits the users' requirements. These database technologies are: 


> IMS Database: Often referred to as DL/I, DL/1, DL1 or DLI databases or 
colloquially as “Full Function databases”: 


IMS Full Function Databases were design to support most types of database 
requirements. These can be used in a wide variety of applications. Most IMS 
applications make use of Full Function databases unless there are specific 
requirements for one of the other types of databases. 


The major characteristics of Full Function databases are: 

¢ Small or large databases. 

« Access to records through unique or non-unique keys. 

* Many types of segments (up to 15 levels allowed). 

¢ Records can be stored in key sequence, but it is not a requirement. 


Note: DL/I is an acronym meaning Data Language | (programming language 1) and 
DL/I is also used colloquially to refer to the database. IMS is the generic name 
of the IBM provided code to interpret the customers application, and manage 
the data stored in the (DL/I or IMS) database, and request z/OS services on 
behalf of the application. 
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> IMS DEDB: The Data Entry database, often referred to colloquially as “Fast Path 
databases”: 


The Data Entry Database (DEDB) was designed to support particularly intensive IMS 
database requirements, primarily in the banking industry, for: 


¢ Large databases containing millions of records, extending well beyond the 
original 4GB database limits of DL/I databases 


* Access to each database record that can be achieved by access through a key 
field 


¢ Lower processing costs per database record and per update than are required 
for DL/I databases 


¢ The capability to support higher transaction workloads than DL/I can sustain, 
while maintaining the per-transaction cost advantages mentioned above 


¢ Improved availability, with reduced requirements for database outage, 
especially for database maintenance activities such as database 
reorganizations 


* Lower processing costs for particular types of processing, where data are 
inserted online and retrieved in batches for further processing, and eventually 
deleted in batches 


¢ The possibility of eliminating transaction-related I/O from database 
processing. 


All the above requirements were satisfied, while maintaining the conventional DL/I 
application interface, so that application programming for the exploitation of DEDBs 
is little different from that for DL/I databases. 


> IMS MSDB: Main storage databases and Database 2 (DB2) 


IMS applications running in an IMS subsystem can also access data stored in a DB2 
database. The updating of the DB2 tables is coordinated with the update to the IMS 
resources (databases and messages) to ensure all updates are consistently applied. 


While the IMS databases provide high performance for the transaction processing 
environment, you may also want to perform ad-hoc queries on all or part of the data, 
more suitable to the relational database model implemented by DB2. You will learn 
more about DB2 in Chapter Appendix 14, “Overview of DB2 on z/OS”. 


13.1.5 Database Recovery Control (DBRC) 


DBRC is that part of IMS which provides the recovery services so much a part of the 
IMS system. DBRC controls the allocation and use of all IMS logs in an online 
environment. We mention it here, because DB2 also makes us of DBRC. 
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13.2 Structure of the IMS Database Subsystem 


This section describes the various types of z/OS address spaces and their relationship 
with each other. The core of an IMS subsystem is the control region, running in one z/OS 
address space. This will have a number of dependent address spaces running in other 
regions that provide additional services to the control region, or in which the IMS 
application programs run. 


In addition to the control region, some applications and utilities used with IMS run in 
separate batch address spaces. These are separate to an IMS subsystem and its control 
region, and have no connection with it. 


For historical reasons, some documents describing IMS use the term region to describe a 
z/OS address space, for example, IMS Control Region. In this course we have used the 
term region wherever this is in common usage. You can take the term region as being the 
same as a z/OS address space. 


Figure 13-2 gives you an idea of the IMS DB/DC subsystem, some details are described, 
if you want more, we refer you to IBMs JMS Primer. 
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Figure 13-2 Structure of IMS DB/DC subsystem 
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13.2.1 IMS Control Region 


The control region (CTL) is a z/OS address space that can be initiated by the system 
operator through a START command, or by submitted JCL. The IMS control region 
provides the central point for an IMS subsystem. It provides the interface to the SNA 
network for the Transaction Manager functions, and the Transaction Manager OTMA 
interface for access to non-SNA networks. It provides the interface to OS/390 for the 
operation of the IMS subsystem. It controls and dispatches the application programs 
running in the various dependent regions. 


The control region provides all logging, restart and recovery functions for the IMS 
subsystems. The terminals, message queues, and logs are all attached to this region, and 
the Fast Path database data sets are also allocated by the CTL region address space. 


A type 2 supervisor call routine (SVC) is used for switching control information, 
message and database data between the CTL region, and all other regions, and back. 


13.2.2 IMS System Dependent Regions 
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The control region will have a number of dependent system address spaces (dependent 
regions) to provide some of the services of the IMS subsystem. These dependent regions 
are automatically started by the IMS control region as part of its initialization, and the 
control region will not complete initialization until these dependent regions have started 
and connected to the IMS control region. 


Every IMS control region has a DBRC region. The other two dependent system address 
spaces are optional, depending on the IMS features used. For the DL/I, separate address 
space options can be specified at IMS initialization. 


DBRC Region 


This address space contains the code for the DBRC component of IMS. It processes all 
access to the DBRC recovery control data sets (RECON). It also performs all generation 
of batch jobs for DBRC, for example, for archiving the online IMS log. All IMS control 
regions have a DBRC address space, as it is needed, at a minimum, for managing the 
IMS logs. 


DL1 Separate Address Space (DLISAS) 


This address space performs most data set access functions for the IMS Database 
Manager component (except for the fast path DEDB databases, described later). The FF 
database data sets are allocated by this address space. 


It also contains some of the control blocks associated with database access and some 
database buffers. This address space is not present with a DCCTL system, since the 
Database Manager component is not present. 
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For a DBCTL control region, this address space is required, and always present. 


For a DB/DC control region, you have the option of having IMS database accesses 
performed by the control region, or having the DB/DC region start a DL/I separate 
address space. For performance and capacity reasons, you would normally use a DLI 
separate address space. 


Common Queue Server Address Space (CQSAS) 


This is used by IMS DCCTL and DB/DC control regions only if they are participating in 
an z/OS sysplex sharing of the IMS message queues. It provides access to the shared IMS 
message queues in the sysplex coupling facility, which replace the IMS messages queue 
data sets on DASD. 


13.2.3 Application Dependent Regions 


IMS provides dependent region address spaces for the execution of system and 
application programs that use the services provided by the IMS. The previously 
discussed region types (DBRC and DLISAS), are automatically started by the IMS 
control region. These application dependent regions are started as the result of JCL 
submission to the operating system by the IMS CTL region, following an IMS command 
being entered. 


Once they are started, the application programs are scheduled and dispatched by the 
control region. In all cases, the z/OS address space executes an IMS region control 
program. The application program is then loaded and called by the IMS code. 


There can be up to 999 application dependent regions connected to one IMS control 
region, made up of any combination of the following dependent region types: 

> Message processing region (MPP) 

> IMS Fast Path region (IFP) 

> Batch message processing region (BMP) 

> DBCTL thread (DBT) 


> Other utility type regions, such as HSSP processing (BMH) and Fast Path utility 
program (FPU) 


Message Processing Region (MPP) 

This type of address space is used to run applications to process messages input to the 
IMS Transaction Manager component (that is, online programs). The address space is 
started by IMS submitting the JCL as a result of an IMS command. The address space 
does not automatically load an application program but will wait until work becomes 
available. 
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There is a complex scheme for deciding which MPP to run the application program. We 
will give a brief description below. When the IMS dispatching function determines that 
an application is to run in a particular MPP region, the application program is loaded into 
that region and receives control. It processes the message, and any further messages for 
that transaction waiting to be processed. Then, depending on options specified on the 
transaction definition, the application either waits for further input, or another application 
program will be loaded to process a different transaction. 


IMS Fast Path Message Region (IFP) 


These address spaces also run application programs to process messages for transactions 
which have been defined as Fast Path transactions. 


IMS Transaction Manager component, the applications are broadly similar to the 
programs that run in an MPP. Like MPRs, the IFP regions are started by the IMS control 
regions submitting the JCL as a result of an IMS command. The difference with IFP 
regions is in the way IMS loads and dispatches the application program, and handles the 
transaction messages. To allow for this different processing, IMS imposes restrictions on 
the length of the application data that can be processed in an IFP region as a single 
message. 


Batch message processing region (BMP) 

Unlike the other two types of application dependent regions, the BMP is not started by 
the IMS control region, but is started by submitting a batch job, for example by a user 
through TSO, or through a job scheduler such as Tivoli Workload Scheduler. The batch 
job then connects to an IMS control region defined in the execution parameters. 


There are two types of applications run in BMP address spaces: 


> Message Driven BMPs (also called transaction oriented), which read and process 
messages off the IMS message queue. 


> Non-message BMPs (batch oriented), which do not process IMS messages. 
BMPs have access to the IMS databases, providing that the control region has the 


Database Manager component installed. BMPs can also read and write to z/OS sequential 
files, with integrity, using the IMS GSAM access method DBCTL Thread (DBT) 


13.2.4 Internal Resource Lock Manager (IRLM) 
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There is one final address space that is, optionally, used with IMS. This is the IRLM 
address space, and is only needed if you are going to use block level or sysplex data 
sharing for the IMS databases. The system operator starts the IRLM address space before 
the IMS control region, through the START command. If the start up parameters specify 
use of IRLM, the IMS control region connects to the IRLM specified on startup, and does 
not complete initialization until connected. 
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There is one IRLM address space running on each z/OS system to service all IMS 
subsystems sharing the same set of databases. IRLM is delivered as an integral part of the 
IMS program product, though as mentioned, you do not have to install or use it unless 
you wish to perform block level or sysplex data sharing. IRLM is also used as the (only) 
lock manager for the DB2 database program product, and for DB2 you must install 
IRLM. 


13.3 Databases used by IMS 


13.3.1 Database basics 


Chapter Appendix 11, “Overview of online applications and databases on z/OS” gave an 
overview of basic database concepts. Some additional information on IMS databases will 
be handled in this chapter, but this will not be complete. For more details on database 
models, visit your favorite local bookshop or Web site. For more details on IMS database 
design options, see the IMS library. 


Access paths in IMS 


Each application function bears in its input some kind of identification with respect to the 
entities used (for example, the part number when accessing a Parts database). These are 
referred to as the access paths of that function. In general, functions require random 
access, although for performance reasons sequential access is sometimes used. This is 
particularly true if the functions are batched, and if they are numerous, relative to the 
database size, or if information is needed from most database records. For efficient 
random access, each access path should utilize the entities key. With proper database 
design, DL/I generally provides fast physical access via a key. Therefore, identification 
of the functions access path is essential for a design to yield good performance. 


Normalization within IMS 


Some of the goals of normalization, which are relevant to the final (hierarchical) IMS 
database design, are to get the data model to a state where: 


1. All entities are uniquely identified. 


2. There is only one occurrence of each data attribute in each entity, that is, it has no 
repeating fields. 


3. There are no many-to-many relationships between entities. 


To transfer the data model to a physical IMS database design, you must achieve the first 
goal for entities that will become root segments. It can also aid the design if you try and 
achieve this for other entities that will become dependents. 


To achieve the second goal, normalization will create a new entity to contain each of the 
occurrences of the data attribute, that will have a one to many relationship with the 


Chapter 13. Overview of IMS onz/OS_ 13-11 


Chapter13 IMS.fm Draft Document for Review December 3, 2004 3:15 pm 


original entity. If there is only a fixed number of occurrences of the attribute, and you are 
certain there will only ever be that maximum number of occurrences, then you may want 
to leave the attribute in the entity. If you are unsure of the number of occurrences, its 
better to create another entity. 


If you leave a many to many relationship in the data model, then it is not possible to 
implement this in an IMS database. Normalization will create another new entity in the 
path of the relationship that has a one to many relationship with each of the two original 
entities. 


If you do decide to normalize the data model, you should adopt a pragmatic approach 
when you map the design to physical IMS databases. You may want to go back on some 
of the changes you made for normalization for performance reasons. Normalization is 
just a technique for getting a data model that provides a sound starting point for the 
physical design. 


13.3.2 The IMS hierarchical database model 
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IMS uses a hierarchical model as the basic method of storing data. Which is the result of 
theoretical work, this arrives as a pragmatic way of storing the data and implementing the 
relationships between the various type of entities. 


In this model, the individual entity types are implemented as segments in a hierarchical 
structure. The hierarchical structure is determined by the designer of the database, based 
on the relationship between the entities and the access paths required by the applications. 


Note that in the IMS program product itself, the term database is used slightly differently 
to its use in other DBMSs. In IMS, a database is commonly used to describe the 
implementation of one hierarchy, so that an application would normally access a large 
number of IMS databases. Compared to the relational model, an IMS database is 
approximately equivalent to a table. 


DL/I allows a wide variety of data structures. The maximum number of different segment 
types is 255 per hierarchical data structure. A maximum of 15 segment levels can be 
defined in a hierarchical data structure. There is no restriction on the number of 
occurrences of each segment type, except as imposed by physical access method limits. 


Sequence to access the segments 


The sequence of traversing the hierarchy is top to bottom, left to right, front to back (for 
twins). 


Segment codes numbers do not take twins into account and sequential processing of a 
database record is in hierarchic sequence. All segments of a database record are included 
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so twins do have a place in hierarchic sequence. Segments may contain sequence fields 
which will determine the order in which they are stored and processed. 
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Figure 13-3 The sequence 


The hierarchical data structure in Figure 13-3 describes the data of one database record as 
seen by the application program. It does not represent the physical storage of the data. 
The physical storage is of no concern to the application program. 


The basic building element of a hierarchical data structure is the parent/child relationship 
between segments of data, also illustrated in Figure 13-3. 


Additional access paths to segments 


In addition to the basic hierarchical DB access paths facilities discussed so far (see 
“Sequence fields and access paths” on page 11-18), IMS provides two additional 
methods of defining access paths to a database segment. These are: 


> Logical relationships 
> Secondary indices 


Both provide a method for an application to have a different access path to the physical 
databases. They are defined to IMS in addition to the basic hierarchical structure already 
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defined. The logical relationships and secondary indices are automatically maintained by 
IMS, transparent to the application. 


Logical relationships allow a logical view to be defined of one or more physical 
databases.To the application this will look like a single database. Secondary indices give 
an alternate access path, via a root or dependent segment, to the database record in one 
physical database. 


You should only use these extra facilities if there are strong application and/or 
performance reasons for doing so. Both involve additional overheads. To learn more 
about both, see JMS Primer. 


13.4 Application programming overview 


This chapter gives a flavour of the basics for any programming running in an IMS 
environment. Details and complete explanations can be found in reference books. We 
introduce it via two sections: 


> Overview of application programs 


> Application program structure 


13.4.1 Overview 


13-14 


IMS programs (online and batch) have a different structure than non-IMS programs. An 
IMS program is always called as a subroutine of the IMS region controller. It also has to 
have a program specification block (PSB) associated with it. You can say that a PSB is a 
program view of the databases. The PSB provides and interface from the program to IMS 
services which the program needs to make use of. These services can be: 


> Sending or receiving messages from online user terminals 
> Accessing database records 
> Issuing IMS commands 
> Issuing IMS service calls: 
— Checkpoint calls 
— Syne call 


The IMS services available to any program are determined by the IMS environment in 
which the application is running. 


Remember that we have different lots of database records in a database. A database 
record contains one root and all its dependencies. The sequential processing order is from 
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top-to-bottom, from front-to-back and than from left-to-right. All segments before the 
one you want, have to be read. 


13.4.2 Program structure 


During initialization, both the application program and its associated PSB are loaded 
from their respective libraries by the IMS system. The IMS modules interpret and 
execute database CALL requests issued by the program. These modules may reside in the 
same or different MVS address spaces depending on the environment in which the 
application program is executing. 


Application programs executing in an online transaction environment are executed in a 
dependent region called the message processing region (MPR). The programs are often 
called message processing programs (MPP). The IMS modules which execute online 
services will execute in the control region (CTL) while the database services will execute 
in the DL/I separate address space (DLISAS). The association of the application program 
and the PSB is defined at IMS system generation time via macros. 


Batch application programs can execute in two different types of regions: 


1. Application programs which need to make use of message processing services or 
databases being used by online systems are executed in a batch message processing 
region (BMP). 

2. Application programs which can execute without messages services execute in a DL/I 


batch region. 


For both these types of batch application programs, the association of the application 
program to the PSB is done on the PARM keyword on the EXEC statement. 


The application program interfaces with IMS via the following program elements: 


> AnENTRY statement specifying the Program communication Block (PCB)s utilized 
by the program 


>» A PCB-mask which corresponds to the information maintained in the pre-constructed 
PCB and which receives return information from IMS 


> An I/O for passing data segments to and from the databases 
> Calls to DL/I specifying processing functions 


> A termination statement 


The PCB masks and I/O areas are described in the programs data declaration portion. 
Program entry, calls to IMS processing, and program termination are described in the 
programs procedural portion. Calls to IMS, processing statements, and program 
termination may reference PCB masks and/or I/O areas. In addition, IMS may reference 
these data areas. Figure 13-4 on page 13-16 illustrates how these elements are 
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functionally structured in a program and how they relate to IMS. The elements are 
discussed in the text that follows: 
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Figure 13-4 Structure of an application program 


Entry to application program 

Referring to Figure 13-4, when the operating system gives control to the IMS control 
facility, the IMS control program in turn passes control to the application program 
(through the entry point as defined below). At entry, all the Program communication 
Block (PCB)-names used by the application program are specified. The order of the 
PCB-names in the entry statement must be the same as in the PSB for this application 
program. The sequence of PCBs in the linkage section or declaration portion of the 
application program need not be the same as in the entry statement. 


Notes: 


1. Batch DL/I programs cannot be passed parameter information via the PARM field 
from the EXEC statement. 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter13 IMS.fm 


2. Online PCBs must proceed database PCBs in the PSB. 


Termination 

At the end of the processing of the application program, control must be returned to the 
IMS control program. Table 13-1 on page Chapter 13.-17 shows examples of the 
termination statements. 


Table 13-1 Program return statements 


COBOL GOBACK. 


ASSEMBLER RETURN(14,12),RC=0 





Warning: Since IMS links to your application program, return to IMS causes storage 
occupied by your program to be released. Therefore you should close all non-DL/I data 
sets for COBOL and Assembler before return, to prevent abnormal termination during 
close processing by MVS. PL/I automatically causes all files to be closed upon return. 


Calls to IMS 


Actual processing of IMS messages, commands, databases and services are 
accomplished using a set of input/output functional call requests. A call request is 
composed of a CALL statement with an argument list. The argument list will vary 
depending on the type of call to be made.The argument list will consists of the following 
parameters: 

> Function call 

> PCB name 

> IOAREA 


> Segment search argument (SSA) (database calls only) 
To find out more on the programming details, see JMS Application Programming: Design 


Guide, IMS Application Programming: Database Manager and/or IMS Application 
Programming: Transaction Manager. 


13.4.3 IMS use of z/OS Services 


IMS is designed to make the best use of the features of the z/OS operating system. This 
includes: 


1. Running in multiple address spaces - IMS subsystems (except for IMS/DB batch 
applications and utilities) normally consist of a control region address space, 
dependent address spaces providing system services, and dependent address spaces 
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for application programs. Running in multiple address spaces gives the following 
advantages: 


« Maximizes use of CPUs when running on a multiple processor CPC. 
« Address spaces can be dispatched in parallel on different CPUs. 


¢ Isolates the application programs from the IMS systems code. Reduces 
outages from application failures. 


2. Runs multiple tasks in each address space - IMS, particularly in the control regions, 
creates multiple z/OS subtasks for the various functions to be performed. This allows 
other IMS subtasks to be dispatched by z/OS while one IMS subtask is waiting for 
system services. 


3. IMS uses z/OS cross memory services to communicate between the various address 
spaces making up an IMS subsystem. It also uses the z/OS Common System Area 
(CSA) to store IMS control blocks that are frequently accessed by the address spaces 
making up the IMS subsystem. This minimizes the overhead in running in multiple 
address spaces. 


4. IMS uses the z/OS subsystem feature to detect when dependent address spaces fail, 
prevent cancellation of dependent address spaces, and to interact with other 
subsystems like DB2 and WebSphere MQ. 


5. IMS can make use of a z/OS sysplex (see later in this book). Multiple IMS 
subsystems can run on the z/OS systems making up the sysplex and access the same 
IMS databases. This provides: 


¢ Increased availability - z/OS systems and IMS subsystems can be switched in 
and out without interrupting the service. 


¢ Increased capacity - the multiple IMS subsystems can process far greater 
volumes. 


13.4.4 Evolution of IMS 


Initially, all IMS/DB online applications used IMS/TM as the interface to the database. 
However, with the growing popularity of DB2, many customers began to develop online 
applications using DB2 as a database, next to their existing good applications. That is 
why you so a lot of mixed environment in the real world. 


13.4.5 Our online example 


When we look back to our travel agent example of Appendix 11, “Overview of online 
applications and databases on z/OS”, examples of IMS transactions could be in the part 
of the airline company: 


> some of the batch part may be to update daily, the payments done by travel agents and 
other customers 
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> another batch part may be the reminders to send out to the travel agent and other 
customers to do some payment 


> checking if reservations is made (and paid) can be an online application 


> checking if there are still available seat may be an IMS transaction 


13.5 IMS and the World Wide Web 


IMS has been evolving into the open, distributed client/server and parallel sysplex 
environments. IMS is also a key product for storing data and providing storage 
efficiency, performance and availability, as well as security, integrity, and cost efficiency 
for the new world of the Internet. 


IMS customers can make their IMS applications and data available to all users across the 
Internet. World Wide Web access is also available today to IMS applications and data 
through currently available communication protocols, for example, MQSeries, 
DCE/RPC, APPC and TCP/IP. 


13.5.1 The World Wide Web: An IMS Perspective 


The World Wide Web and the Internet are the hottest topics in the IT world today. It is not 
possible to pick up a newspaper without seeing an article on these technologies. 


Back in the real world of running the core operations of the business, IMS continues to 
play a critical role in the Information Technology infrastructure. The question now being 
asked is: 


> How can I make my core business applications available to the Internet? 


13.5.2 The Transaction Model 


The World Wide Web is very similar in concept to the transaction processing model that 
has been used by IMS for over 30 years. 


Consider the following scenario: 


1. The user enters data onto a form displayed at their terminal, and presses the enter key 
to submit the transaction. 

2. The networking software moves the data from the terminal across the network. 

3. The networking software delivers the data to a transaction manager. 

4. The transaction manager looks to see what transaction has been requested, and 
schedules the appropriate application program. 
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5. The transaction manager passes the data to the application programs which processes 
the transaction. 

6. A reply message is created by the application program, and is passed back to the 
transaction manager. 

7. The transaction manager passes the reply message to the network software. 

8. The network software passes the message across the network back to the terminal. 

9. The result of the business transaction is displayed upon the terminal. 


In the traditional IMS world, the software involved in these same steps is shown in 
Figure 13-5: 


1. The data is entered into the fields on the form displayed on the 3270 screen and the 
Enter key is pressed. 

2. The 3270 screen puts the data into a buffer, and to NCP, who will pass the message 

along to VTAM. 

VTAM passes the data along to IMS. 

IMS identifies the transaction code from the message, and schedules the appropriate 

message processing program (MPP). 

The MPP receives the message from IMS and processes the transaction. 

The results of the transaction are passed back to IMS via the Insert call. 

IMS passes the message to VTAM, who passes the message to the terminal. 

VTAM passes the message to the terminal. 

The results of the transaction are displayed on the terminal. 


12 3 4,5 
——_——_—_ 
i 
NCP VTAM IMS 
8,9 w 
3270 Terminal —_—— 


Figure 13-5 Message Flow through an IMS Transaction 
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Now let us look at the scenario where the user is sitting at a personal computer (PC) with 
a Web browser, as shown in Figure 13-6 on page 13-21. 


1. The fields on the form are filled in, and the enter key is pressed. 

2. The Web browser puts the data into a string, and passes it to TCP/IP using the 

hypertext transfer protocol (HTTP). 

TCP/IP passes the message along to the Web server. 

4. The Web server identifies the transaction code from the message, and schedules the 
CGI program that can process this transaction type. 


uo 
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5. The CGI program receives the message from the Web server, and processes the 


transaction. 
The results of the transaction are passed back to the Web server. 

The Web server passes the message to TCP/IP. 

TCP/IP passes the message to the PC, using the HTTP protocol. 

The results of the transaction are displayed on the PC. 

CGI 
Program 

As you can see, the flow of information, and the software used to achieve this, are very 
much the same for both traditional IMS and the new Internet world. 


we amr 








Web Browser 











Figure 13-6 Message Flow between a Web Browser and a Web Server 


Now let us extend this model a little. If we wish to have the output of an IMS transaction 
available through the World Wide Web, we need to look more closely at step 5. In this 
step, the application program has been passed the data, ready to be processed. If the data 
has come from the Web, then this program is a CGI program running under the control of 
the Web server. We now need the CGI program to pass the transaction along to IMS, so 
the transaction can be processed by an IMS MPP. This is shown in Figure 13-7. 
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Figure 13-7 Message flow IMS transaction and Web Server CGI Programs 


We have now reached the crux of the problem. The initial question, “How can I make my 
core business applications available to the Internet?” can now be answered. All it takes is 
to extend the CGI program that receives the data from a Web browser, and pass this data 
along to IMS as a transaction. The question now becomes one of getting the Web 
program to communicate with IMS. 


Over the past few years, IMS has greatly increased the number of options available for 
communication with the outside world. Many of these options are described in a redbook, 
Connecting IMS to the World Wide Web, A Practical Guide to IMS Connectivity. 


13.6 Summary 


In this chapter you have learned the different components of IMS and their connection to 
the mainframe. What address spaces are used to run IMS. Next to that, you have seen 
what databases are implementable in IMS and what the difference is between them. 
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The structure of the IMS database subsystem learns you what part belongs where on the 
mainframe. 


We continued with the IMS specifics point of view DB, to end up in the application 
programming overview and its structure. 


Last but not least these days, we have learned how IMS can be used for Web-enablement. 
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13.7 Discussion questions 


What are the major components and their tasks within IMS? 

What database technologies are used by IMS and explain them? 
What is IRLM and what uses it? 

How are segments read in a database record and think of an example? 


What is a region in IMS and explain some of them? 


ov Rw Ne 


Compare the IMS message flow with the Web Server-Web browser flow 
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13.8 Instructor notes 


13.8.1 refer to 13.2, “Structure of the IMS Database Subsystem” on 
page 13-7: Network Access to IMS 


IMS is written to interact with networks through IBM Systems Network Architecture 
(SNA), as currently implemented using the VTAM program product. It can also be 
accessed by networks using Transmission Control Protocol/ Internet Protocol (TCP/IP). 


The Transaction Manager interacts directly with VTAM. Access using TCP/IP is made 
through another address space, this address space uses the IMS Open Transaction 
Manager Access (OTMA) function. The other address space can be either one available 
with IMS, such as the IMS TCP/IP OTMA Connector (ITOC), or another program 
product such as IBMs WebSphere MQ (more about this in Appendix 16, “Messaging and 
queuing on z/OS”). 


13.8.2 refer to 13.2.1, “IMS Control Region” on page 13-8: more 
details 


These three Control regions are: 


> DB/DC - This is a control region with both Transaction Manager and Database 
Manager components installed. It provides the combined functionality of both the 
other two types of control region. Note that when a DB/DC region is providing access 
to IMS databases for a CICS region, it is referred to in some documentation as 
providing DBCTL services, though it may in fact be a full DB/DC region and not just 
a DBCTL region. 


> DBCTL - This is a control region with only the Database Manager component 
installed. This can provide IMS database functions to batch application programs 
connected to the IMS control region (BMPs, see below), to application transactions 
running in CICS Transaction Manager regions, and to other z/OS address spaces (for 
example, DB2 stored procedures) through the Open DataBase Access (ODBA) 
interface. 


> DCCTL - This type of control region has only the Transaction Manager component 


installed. It provides access to the IMS message queues for IMS applications running 
in the MPP, IFP and BMP application address spaces described below. 


13.8.3 refer to 13.2.3, “Application Dependent Regions” on page 13-9 
more details on IFP 


IMS employs a user exit, which you have to write, to determine whether a transaction 
message should be processed in an IFP region, and which IFP region it should be 
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processed in. The different dispatching of the transaction messages by the control region 
is called Expedited Message Handling (EMH). The intention is to speed the processing of 
the messages by having the applications loaded and waiting for input messages, and, if 
the message is suitable, dispatching it directly in the IFP region, bypassing the IMS 
message queues. 


Fast Path was originally a separately priced function available with IMS, intended to 
provide faster response and allow higher volumes of processing. It is now part of the IMS 
base product. 


Batch message processing region (BMP) 


Unlike the other two types of application dependent regions, the BMP is not started by 
the IMS control region, but is started by submitting a batch job, for example by a user 
through TSO, or through a job scheduler such as Tivoli Workload Scheduler. The batch 
job then connects to an IMS control region defined in the execution parameters. 


There are two types of applications run in BMP address spaces: 


> Message Driven BMPs (also called transaction oriented), which read and process 
messages off the IMS message queue. 


> Non-message BMPs (batch oriented), which do not process IMS messages. 
BMPs have access to the IMS databases, providing that the control region has the 


Database Manager component installed. BMPs can also read and write to z/OS sequential 
files, with integrity, using the IMS GSAM access method DBCTL Thread (DBT) 


When a CICS system connects to IMS DBCTL, or to an IMS DB/DC system using 


DBCTL facilities, each CICS system will have a pre-defined number of connections with 
IMS. Each of these connections is called a thread. 
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Although these threads are not jobs in their own right, from IMS’s perspective, each 
thread appears just like another dependent region, and when CICS requires a DL/I call to 
IMS, the program will effectively be running in one of these DBT. 


Batch Application Address Space 

In addition to the dependent application address spaces above, IMS application programs 
that only use IMS Database Manager functions can be run in a separate z/OS address 
space, not connected to an IMS control region. This would normally be done for very 
long running applications, that perform large numbers of database accesses. 


This is similar to a BMP, in that the JCL is submitted through TSO or a job scheduler. 
However, all IMS code used by the application resides in the address space the 
application is running in. The job executes an IMS region controller that then loads and 
calls the application. 
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The batch address space opens and reads the IMS database data sets directly. If there are 
requirements for other programs, either running in an IMS control region or in other 
batch region, to access the databases at the same time, then see the discussion elsewhere 
in this book on methods of data sharing. 


The batch address space writes its own separate IMS log. In the event of a program 
failure it may be necessary to take manual action (for example, submit jobs to run IMS 
utilities) to recover the databases to a consistent point (with dependent application 
address spaces this would be done automatically by the IMS control region). DBRC, if 
properly set up, can be used to track the IMS logs and ensure that correct recovery action 
is taken in the event of a failure. 


An application can be written so that it can run in both a batch and BMP address space 
without change. Some reasons you may want to change programs between batch and 
BMP address spaces include length of run time, need of other applications to access the 
data at the same time, and your procedures for recovering from application failures. 


13.8.4 Refer to 13.2, “Structure of the IMS Database Subsystem” on 
page 13-7: Running the IMS Subsystems 


The procedures to run IMS address spaces are supplied by IBM. The procedures will be 
available in the PROCLIB data set. There are procedures for each type of region: 
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DB/DC control region 
DCC control region 
DBCTL control region 
DLI separate address space 
DBRC address space 
IRLM address space 
Message processing region (MPR) 
IMS batch region (BMP) 
Fast Path region (IFP) 

Fast Path utility region (*) 
DLI batch region 
IMSRDR region 


vvvvvvvvvvvy 


Running multiple IMS systems on one OS/390 system 

Multiple IMS systems can be run on a single OS/390 image. One instance of an IMS 
system (control region and all dependent regions) is referred to as one IMS subsystem. In 
many cases these would be production and testing subsystems. 


Each IMS subsystem 

Each IMS subsystem should have unique VITAM ACB and IMSID names. The 
application dependent regions use the IMSID to connect to the corresponding IMS 
control region. If the dependent region starts and there is no control region running using 
that IMSID, it will display a message on the z/OS system console and wait for a reply. 
Each IMS subsystem can have up to 99 dependent regions. However, there are other 
limiting factors. 


If the IRLM is used, it must be started before the IMS control region. If IMS starts to 
come up first, it will display a message on the z/OS system console and wait for a reply. 
If the IRLM is specified, IMS will not run without it. 


The number of subsystems you can run on a single image of z/OS will depend on a lot of 
factors. The number will vary depending on the size of each IMS systems. The amount of 
CSA required by each IMS system is often one of the most limiting factors in the 
equation. 


All the address spaces can either run as a started task or as a JOB. In most cases the IMS 
control region and the system dependent regions will run as started tasks. The application 
dependent regions are run as either. 


When a control region is started, it issues a START command as shown in the example 
below: 


/START xxxxxxxx, PARM=(DLS, imsid) 
/START xxxxxxxx,PARM= (DRC, imsid) 
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The xxxxxxx fields are the procedure names. These commands will start the DLISAS 
and DBRC regions respectively. 


13.8.5 refer to 13.3.2, “The IMS hierarchical database model” on 


page 13-12 


Segment A2 Segment B1 
Segment D3 Segment B2 


Segment E1 Segment G1 Segment H1 
Segment E2 Segment G2 
Segment E3 


Segment codes numbers do not take twins into account and sequential processing of a 
database record is in hierarchic sequence. All segments of a database record are included 
so twins do have a place in hierarchic sequence. Segments may contain sequence fields 
which will determine the order in which they are stored and processed. 
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Figure 13-8 


Accessing Segments 
There are a few basic command for accessing an IMS database: 


Retrieval 
Get Unique (GU) 
Read a particular segment as determined by sequence or search fields 
Get Next (GN) 
Read the next segment in hierarchic sequence 
Get Next Within Parent (GNP) 
Read the next segment in hierarchic sequence under a particular parent 


segment 


Update 
Insert (SRT) 


Insert a new occurrence of a segment 
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Delete (DLET) 
Delete a segment 
Replace (REPL) 


Update a segment with a new data, except for the sequence field 


The segments are stored with a prefix and a data portion. The prefix is used only by IMS 
and the data is what the application program uses. Here is the format: 


se | oe | rome | rote fm | ror 








The prefix contains: 

> SC = segment code, | byte 
> DB =delete byte, | byte 

> 0-n pointers, 4 bytes each 


The Sequential Organization 
The data in IMS is physically stored in hierarchic sequence. The specific database 


records are stored in a root key sequence, although if there is no root key, they are stored 
as they are presented. The segments in a record are stored in hierarchic sequence. 
The sequential database types are as follows: 
¢ Hierarchical Sequential Access Method (HSAM) 
¢ Simple Hierarchical Sequential Access Method (SHSAM) 
- Root-only HSAM 
¢ Hierarchical Indexed Sequential Access Method (HISAM) 
¢ Simple Hierarchic Indexed Sequential Access Method (SHISAM) 
- Root-only HISAM using VSAM 
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* Generalized Sequential Access Method (GSAM) 


- No hierarchy, no database records, no segments 


13.8.6 Answers to 13.7, “Discussion questions” on page 13-23 


1. What are the major components and their tasks within IMS? 
— Transaction Manager 
— Database Manager 
— IMS System (to support DM and TM) 
2. What database technologies are used by IMS and explain them? 
— Full Function database (DL/I) 
— Fast Path database (DEDB) 
— IMS Main storage database (MSDB) 
— Database 2 (DB2) 
3. What is IRLM and what uses it? 


It stand for Internal Resource Lock Manager (use to be IMS Resource Lock 
Manager); it is optionally used by IMS, but DB2 uses it frequently to put locks on its 
resources. 


4. How are segments read in a database record and think of an example? 
— Top-to-bottom 
— left-to-right 
—  front-to-back 
5. What is a region in IMS and explain some of them? 
It is an address space. 
6. Compare the IMS message flow with the Web Server-Web browser flow 


This is the Transaction Model, which can be found on 13.5.2, “The Transaction 
Model” on page 13-19. 
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Overview of DB2 on z/OS 








Objective: This chapter explains the main concepts of DB2 and how it fits 
into z/OS. It also introduces the application programming flow and how DB2 
has to be managed. Also how DB2 fits into the Web world is handled. 


In this chapter, you will learn: 


some DB2 concepts 

the DB2 system structure 

DB2 for z/OS architecture 

how to invoke SQL on z/OS 
application programming with DB2 
managing DB2 


vvvvvy 




















14.1 RDBMS on 2/OS 


The general concepts of an RDBMS are discussed in “Relational DBMS (RDBMS) 
Theory” on page 11-19. 


Most table examples in this chapter can be found in Appendix A, “DB2 sample tables”. 
These tables, such as EMP and DEPT, are part of the Sample Database that comes with 
the DB2 product on all platforms. We are using the Version 8 in the screen captures, 
therefor the owner of our tables is DSN8810. 
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14.2 DB2 Concepts 


The elements that DB2 manages can be divided into two categories: data structures 
which are used to organize user data and system structures which are controlled by DB2. 
Data structures can be further broken down into basic structures and schema structures. 
Schema structures are fairly new objects that have been introduced on the mainframe for 
compatibility within the DB2 family. A schema is a logical grouping of these new 
objects. 


14.2.1 Data Structures 


14-2 


Basic Structures 
Most of the basic structures used in all DBRMs are discussed in “Relational DBMS 
(RDBMS) Theory” on page 11-19. Here we describe some more DB2 specific structures. 


Views 

A view is an alternative way of looking at the data in one or more tables. It is like an 
overlay that you would put over a transparency to only allow people to see certain 
aspects of the base transparency. For example, you can create a view on the department 
table to only let users have access to one particular department in order to update salary 
information. You don't want them to see the salaries in other departments. You create a 
view on the table that only lets the users see one department, and they use the view like a 
table. Thus, a view is used for security reasons. Most companies will not allow users to 
access their tables directly, it usually goes via the creation of a view. The users get access 
via the view. A view can also be used to simplify a complex query for naive users. 


Table spaces 

A table is just a logical construct. It is kept in an actual physical data set called a table 
space. Table spaces are storage structures and can contain one or more tables. A table 
space is named using the database name followed by the table space name: 
PAYROLL.ACCNT_RECV. There are three types of table spaces: Simple, Segmented 
and Partitioned table space. You can find more detailed information in DB2 UDB for 
z/OS: SQL Reference. 


Index spaces 


An index space is another storage structure that contains a single index. In fact, when you 
create an index, DB2 will automatically define an index space for you. 


Storage groups 
A set of volumes on disks (DASD) that hold the data sets in which tables and indexes are 
actually stored. 
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Storage group 


> 


Data base 


Table Space 























Index Space 





Figure 14-1 There is a hierarchy to the objects in a DB2 subsystem. 


14.2.2 Schema structures 


User-defined Data Types (UDTs) 

A UDT is a way for the user to define his own data types above and beyond the usual 
character and numeric data types. However, UDTs are based upon the already existing 
DB2 data types. If you dealt in international currencies, you would most likely want to 
differentiate the various types of monies. With a UDT definition, you could define the 
EURO, based on the decimal data type, as a distinct data type in addition to YEN or 
US_DOLLAR. As aresult, you could not add a YEN to a EURO since they are distinct 
data types. 


User-defined Function (UDFs) 

A UDF can be simply defined on an already existing DB2 function, such as rounding or 
averaging, or can be more complex and written as an application program that could be 
accessed by an SQL statement. In our international currency example, we could use a 
UDF to convert one currency value to another in order to do arithmetic functions. 
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Triggers 

A trigger defines a set of actions that are executed when an insert, update, or delete 
operation occurs on a specific table. For example, let's say that every time you inserted an 
employee into your EMP table, you also wanted to add one to an employee count that 
you keep in a company statistics table. You can define a trigger that will get “fired” when 
you do an insert into EMP. This firing will automatically add one to the appropriate 
column in the COMPANY STATS table. 


Large Objects (LOBs) 


A LOB is a data type used by DB2 to manage unstructured data. There are three types of 
LOBs: 


1. Binary Large Objects (BLOBS). These are used for photographs and pictures, audio 
and sound clips, and video clips. 


2. Character Large Objects (CLOBS). These are used for large text documents. 


3. Double Byte Character Large Objects (DBCLOBS) - these are used for storing large 
text documents written in languages that require double byte characters, such as 
Kanji. 


LOBs are stored in special auxiliary tables that use a special LOB table space. In your 
EMP base table, text material such as a resume can be included employee. Since this is a 
large amount of data, it is contained in its own table. A column in the EMP table, defined 
as a CLOB, would have a pointer to this special LOB auxiliary table that is stored in a 
LOB table space. Each column defined as a LOB would have its own associative 
auxiliary table and LOB table space. 


Stored Procedures 


A stored procedure is a user-written application program that typically is stored and run 
on the server (but it can be run for local purposes as well). Stored procedures were 
specifically designed for the client/server environment where the client would only have 
to make one call to the server which would then run the stored procedure to access DB2 
data and return the results. This eliminated having to make several network calls to run 
several individual queries against the database, which can be expensive. You can think of 
a stored procedure as being somewhat like a subroutine that can be called to perform a set 
of related functions. It is an application program, but it is defined to DB2 and managed 
by the DB2 subsystem. 


System Structures 
Catalog/Directory 


DB2 itself maintains a set of tables that contain metadata or data about all the DB2 
objects in the subsystem. The catalog keeps information about all the objects, such as 
the tables, views, indexes, table spaces, etc., while the directory keeps information about 
the application programs. The catalog can be queried to see the object information; the 
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directory can not. When you create a user table, DB2 automatically records the table 
name, creator, its table space, and database in the catalog and puts this information in the 
catalog table called SYSIBM.SYSTABLES. All the columns defined in the table are 
automatically recorded in the SYSIBM.SYSCOLUMNS table. In addition, to record that 
the owner of the table has authorization on the table, a row is automatically inserted into 
SYSIBM.SYSTABAUTH. Any indexes created on the table would be recorded in the 
SYSIBM.SYSINDEXES table. 


Buffer pools 

Buffer pools are areas of virtual storage in which DB2 temporarily stores pages of table 
spaces or indexes. They act as a cache area between DB2 and the physical disk storage 
device where the data resides. A data page is retrieved from disk and placed in a buffer 
pool page. If the needed data is already in a buffer, expensive I/O access to the disk can 
be avoided. 


Active and Archive Logs 


DB2 records all data changes and other significant events in a log. This information is 
used to recover data in the event of a failure, or DB2 can roll the changes back to a 
previous point in time. DB2 writes each log record to a data set called the active log. 


When this is full, DB2 copies the contents of the active log to a disk or tape data set 
called the archive log. 


In conjunction with the active and archive log data sets, a bootstrap data set keeps track 
of these active and archive logs. DB2 uses this information in recovery scenarios, for 
system restarts, or for any activity that requires reading the log. 


Bootstrap data set (BSDS) 


The bootstrap data set (BSDS) is a VSAM key-sequenced data set (KSDS) that contains 
information critical to DB2. Specifically, the BSDS contains: 


1. An inventory of all active and archive log data sets known to DB2. DB2 uses this 
information to track the active and archive log data sets. DB2 also uses this 
information to locate log records to satisfy log read requests during normal DB2 
system activity and during restart and recovery processing. 


2. A wrap-around inventory of all recent DB2 checkpoint activity. DB2 uses this 
information during restart processing. 


3. The distributed data facility (DDF) communication record, which contains 
information necessary to use DB2 as a distributed server or requester. 


4. Information about buffer pools. 
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Because the BSDS is essential to recovery in the event of subsystem failure, during 
installation DB2 automatically creates two copies of the BSDS and, if space permits, 
places them on separate volumes. 


14.3 DB2 for 2/OS Architecture 


14.3.1 DB2 Address Spaces 


DB2 operates as a formal subsystem of z/OS. It can use five address spaces, of which 
three are considered the major subcomponents: 


System services address space (SSAS) 


This address space is responsible for all logging activities, recovery, and coordinates the 
attachment of DB2 to other subsystems, such as TSO, CICS, or IMS/TM. DSNMSTR is 
the started task that contains the DB2 log. 


Database Services Address Space (DBAS) 


This address space is responsible for the manipulation of DB2 data structures. 


Internal Resource Lock Manager (IRLM) 
This address space is responsible for locking. 


The two additional address spaces are the Stored Procedure Address Space (SPAS) and 
the Distributed Data Facility address space (DDF), which provides access to distributed 
data 


14.3.2 DB2 Attachment Facilities 
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An attachment facility provides the interface between DB2 and another environment. 
The z/OS environments include CICS, IMS, TSO, and batch. The z/OS attachment 
facilities include CICS, IMS, TSO, ete.... 


CICS 


The CICS attachment facility lets you access DB2 from CICS and provides CICS 
applications with access to DB2 data while operating in the CICS environment. If there is 
a system failure, CICS coordinates recovery of both DB2 data and CICS data. 


IMs 


The IMS attachment facility allows you to access DB2 from IMS. The IMS attach facility 
receives and interprets requests for access to DB2 databases by using exit routines that 
are part of IMS subsystems. IMS applications can make calls to DB2 by using embedded 
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SQL statements. In case of system failure, IMS coordinates recovery of both DB2 data 
and IMS data. 


TSO 


The TSO attachment facility is used to bind applications that access DB2 data and to run 
several online functions of DB2. TSO allows authorized DB2 users or jobs to create, 
modify, and maintain databases and application programs. Using the TSO attachment 
facility, you can access DB2 by running in either foreground or batch. There are two 
command processors available with TSO: 1) the DSN command processor and 2) DB2 
Interactive (DB2I). 


14.4 Invoke SQL on z/OS 


Structured Query Language, better known as SQL, is a high-level language that is used to 
specify what information a user needs without having to know how to retrieve it. DB2 is 
responsible for developing the access path needed to retrieve the data. SQL works at a set 
level, meaning that it is designed to retrieve one or more rows. Essentially, it is used on 
one or more tables and returns the result as a result table. 


SQL has three categories based on the functionality involved: 
1. DML - data manipulation language used to read and modify data. 
2. DDL - data definition language used to define, change, or drop DB2 objects 


3. DCL - data control language used to grant and revoke authorizations 


There are several tools that can be used to enter and execute SQL statements. The one 
that we will focus on here is SPUFI, which stands for SQL Processing Using File Input. 
SPUFI is part of the DB2 Interactive (DB2I) menu panel which is a selection from your 
ISPF panel when DB2 is installed. (This, of course, depends on how your system people 
set up your system's menu panels.) SPUFI is most commonly used by DBAs and system 
people. It allows you to write and save one or more SQL statements at a time. DBAs use 
it to grant/revoke authorizations; sometimes even to create objects, when that needs to be 
done urgently. SPUFI is also often used by developers to test there queries. This way they 
are sure that the query returns exactly what they want. 


Another tool which you might encounter on the mainframe is the Query Management 
Facility (QMF) which allows you to enter and save just one SQL statement at a time. 
QMF's main strength is its reporting facility. It allows you to design flexible and reusable 
report formats, including graphs. In addition, it provides a Prompted Query capability 
that helps users unfamiliar with SQL to build simple SQL statements. Another tool is the 
Administration Tool, which has SPUFI capabilities as well as a query building facility. 
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14.4.1 SPUFI 


Figure 14-2 on page 14-8 shows how SQL is entered using SPUFI. It is the very first 
selection on the DB2I panel. Note that the name of this DB2 subsystem is DB8H. 
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SPUFI 
DCLGEN 


PRECOMPILE 
BIND/REBIN 
RUN 

DB2 COMMAN 
UTILITIES 
DB2I DEFAU 
EXIT 


Kx TAN OORWNHRe 


FE=HELP 
F(=UP 








COMMAND ===> 1_ 


Select one of the following DB2 functions and press ENTER. 


PROGRAM PREPARATION 


D/FREE 


DS 


LTS 


F2=SPLIT 
F8=DOWN 


DB2I PRIMARY OPTION MENU SSID: DB8H 


(Process SQL statements) 

(Generate SQL and source language declarations) 
(Prepare a DB2 application program to run) 
(Invoke DB2 precompiler) 

(BIND, REBIND, or FREE plans or packages) 

(RUN an SQL program) 

(Issue DB2 commands) 

(Invoke DB2 utilities) 

(Set global parameters) 

(Leave DB2I) 


F3=END F4=RETURN FS=RFIND F6=RCHANGE 
F9O=SWAP FLO=LEFT F11=RIGHT F1i2=RETRIEVE 








Figure 14-2 Entering SQL using SPUFI 


SPUFI uses file input and output, so it is necessary to have two data sets pre-allocated: 


> The first, which can be named ’ZPROF.SPUFIL.CNTL, is typically a partitioned data 
set in order to keep or save your queries as members. A sequential data set would 
write over your SQL. 

> The output file, which can be named ’ZPROF.SPUFIL.OUTPUT’, must be sequential 
which means your output is written over for the next query. If you want to save it, you 
must rename the file, using the ISPF menu edit facilities. 


In Figure 14-3 on page 14-9 you can see how that fits in. 
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SPUFI SSID: DB8H 
===> 







Enter the input data set name: artitioned) 
1 DATA SET NAHE ... ===) 
2 ‘VOLUME SERIAL ... ===) 


3 DATA SET PASSWORD ===> 


(Can be sequenti 






(Enter if not cataloged) 
(Enter if password protected) 






data set) 








Enter the output data set name: (Must be as 


4 DATA SET NAHE ... ===) 


Specify processing options: 


5 CHANGE DEFAULTS ===) (Y/N - Display SPUFI defaults panel?) 


6 EDIT INPUT 2.50%: (Y/N - Enter SQL statements?) 

% EXECUTE ss (Y/N - Execute SQL statements?) 

8 AUTOCOMMIT ...... (Y/N - Commit after successful run?) 
9 BROWSE OUTPUT (Y/N - Browse output data set?) 


For remote SQL processing: 


10 CONNECT LOCATION ===> 22 


FLi=HELP F2=SPLIT F3=END F4=RETURN FS=RFIND F6=RCHANGE 
Fr=UP F8=DOWUN F9=SWAP F1IO=LEFT F11=RIGHT F12=RETRIEVE 

















Figure 14-3 Assigning SPUFI data sets 


Notice option 5, which you can change to YES temporarily to see the default values. One 
which you might want to change is the maximum number of rows retrieved. 


With option 5 at NO, if you press the Enter key, SPUFI will put you in the input file, 
*>ZPROF.SPUFI.CNTL(DEPT)’, in order to enter or edit an SQL statement. Also see the 
Warning on top of the screen; by entering “recov on” in the command and pressing 
ENTER, the warning will disappear. This option is part of the profile, mentioned earlier 
in this book. The screen is shown in Figure 14-4 on page 14-10. 
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File Edit Edit_Settings Menu Utilities Compilers Test 





SOK OOK OOOO IDK ROOK OOK ORK IOKOK Top of Dat a 9K 9K 10K KKK KKK KK KK 


Fi=Help F2=Split F3=Exit F5=Rfind F6=Rchange  F7=Up 
F8=Down F9=Swap F10=Left F11=Right F1i2=Cancel 











Figure 14-4 Editing the input file 


If your profile is set to “CAPS ON”, the SQL statement you have just typed will normally 
change to capital letters at the enter. But this is not needed. 


Notice that we have mentioned “DSN8810.DEPT” as table name. This is the qualified 
name of the table, since we want to use the sample tables. The sample tables are created 
by the user DSN8810. 


If you enter just one SQL statement, you do not need to use the SQL terminator (;) since 
this is specified in the defaults (but you can change this, remember option 5 of the 
previous screen). However, if you enter more than one SQL statement, you will need to 
use a semicolon at the end of each statement to indicate that you have more than one. 


At this point, you need to go back to the first panel of SPUFI by hitting the F3 key. You 
will then see Figure 14-5 on page 14-11. 
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SPUFI 


===) 


Enter the input data set name: 


1 DATA SET NAME 
2 VOLUME SERIAL 
3 DATA SET PASSWORD ===> 


Enter the output data set name: 
4 DATA SET NAME ===) 


Specify processing options: 


5 CHANGE DEFAULTS ===) 

6. EDIT INPUT. 0.44 a6 = 

7 (ERECUIES ici nnceroe 

® AUTOCOHMIT — ac... 

9 BROWSE OUTPUT 

For remote SQL processing: 

10 CONNECT LOCATION ===> 

F1=H 

Fr=UP F8=DOWN F9=SWAP 












SSID: DB8H 


(Can be sequential or partitioned) 






(Enter if not cataloged) 
(Enter if password protected) 


(Must be a sequential data set) 






Display SPUFI defaults panel?) 


(Y/N - Enter SQL statements?) 

(Y/N - Execute SQL statements?) 

(Y/N - Commit after successful run?) 
(Y/N - Browse output data set?) 


HANGE 
F12=RETRIEVE 


F1Q=LEFT 


F11=RIGHT 








Figure 14-5 Returning to the first SPUFI panel 


Notice that there is an asterisk after option 6 since you just finished editing your SQL. At 
this point, if you press Enter, you will execute your SQL statement and you will 
automatically be put into your output file, since “BROWSE OUTPUT” is set to “YES”. 
The first part of the output you see in Figure 14-6 on page 14-12. To get the second (and 
in this case final) result screen, press F8; see Figure 14-7 on page 14-12 
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Menu Utilities Compilers Help 





select deptno 
from dsn8810.dept 


Fl=Help F2=Split F3=Exit FS=Rf ind F7=Up F8=Down F9=Swap 
F10=Left Fii=Right F12=Cancel 

















Menu Utilities Compilers Help 





NUMBER OF ROWS DISPLAYED IS 14 
STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100 


COMMIT PERFORMED, SQLCODE IS 0 

STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 0 

+--------- +--------- +--------- $--------- $--------- $--------- +--------- 4 
SQL STATEMENTS ASSUMED TO BE BETWEEN COLUMNS 1 AND 72 

NUMBER OF SQL STATEMENTS PROCESSED I$ 1 

NUMBER OF INPUT RECORDS READ IS 2 

NUMBER OF OUTPUT RECORDS WRITTEN I$ 38 


bOI IOQOK OOK OKIKKOROROKOKOKKOKKKMOK KKK Bottom of Data > #>K KOK KKK KOK KOK ROKK KKK KOR OK KOK 


Fi=Help F2=Split F3=Exit F5=Rf ind F7=Up F8=Down F9=Swap 
Fi0=Left Fli1=Right F12=Cancel 











Figure 14-7 Second result screen 
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Notice that you have a result table with just one column. This is what was specified in the 
SELECT, just DEPTNO. We have retrieved the DEPTNO from all the (14) rows in the 
table. There are a few messages; one gives the number of rows retrieved. Another 
indicates that the SQLCODE, an SQL return code indicating success or not, is 100 which 
means end of file, no more results to show. 


14.5 Application Programming 


Structured Query Language (SQL) is not a full programming language but it is necessary 
to access and manipulate data in a DB2 database. SQL is a 4GL non-procedural language 
that was developed in the mid 1970’s to use with DB2. SQL can either be used 
dynamically with an interpretive program like SPUFI, or it can be imbedded and 
compiled or assembled in a host language (such COBOL, PL/I, Assembler,....). 


So how do you write an application program that accesses DB2 data? 


To do this, SQL is embedded in the source code of a programming language. SQL can be 
used with the following programming languages: Java, Smalltalk, REXX, C, C+4, 
COBOL, Fortran, PL/I, and high-level Assembler. There are two categories of SQL 
statements that can be used in a program: static and dynamic. 


> Static: SQL refers to complete SQL statements that are written in the source code. In 
the program preparation process, DB2 develops access paths for the statements, and 
these are recorded in DB2. The SQL never changes from one run to another, and the 
same determined access paths are used without DB2 having to create them again, a 
process that can add overhead. (Note: all SQL statements must have an access path.) 


> Dynamic: SQL refers to SQL statements that are only partially or totally unknown 
when the program is written. Only when the program runs does DB2 know what the 
statements are and is able to determine the appropriate access paths. These do not get 
recorded since the statements can change from one run to another. An example of this 
is SPUFI. SPUFI is actually an application program that accepts dynamic SQL 
statements. These are the SQL statements that you enter in the input file. Each time 
you use SPUFI, the SQL can change, so special SQL preparation statements are 
embedded in the application to handle this. 


As of now, we are concentrating on STATIC SQL, to have an idea of the involved 
processes if you are using DB2. We also want to add that it may seem complex, but each 
action has its good reason for being there. 


14.5.1 DB2 Program Preparation: the flow 


The traditional program preparation process, compile/linkedit, must have some 
additional steps to prepare SQL because compilers do not recognize SQL. These steps, 
including compile/linkedit, can be done with the DB2I panel although the whole process 
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is usually done in one JCL jobstream except for the DCLGEN. Use Figure 14-8 on 
page 14-15 when going through the explanations. 


DCLGEN 


DCLGEN is a way to automatically generate your source definitions for the DB2 objects 
that will be used in your program. This is set up in a member of a DCLGEN library 
which can optionally be included in your source program. If you do not include it, you 
must manually code the definitions. The DB2 database administrator usually creates 
these, based on the companies rules. During this phase, you need a running DB2 system, 
because the definitions are taken from the DB2 catalog. 


PRECOMPILE 


Because compilers can not handle SQL, the precompile step comments out the SQL 
statements and leaves behind a CALL statement to DB2. This passes some parameters 
such as host variable addresses (to retrieve data into), statement numbers, and (very 
importantly!) a modified timestamp called a consistency token (but often referred to as 
the timestamp). During this phase, you do not need a running DB2 system, everything is 
done without accessing DB2. 


The precompiler identifies the SQL by special beginning and ending flags that must be 
written for each SQL statement. The beginning flag, EXEC SQL, is the same for all 
programming languages. The ending flag differs. COBOL uses END-EXEC. (period), 
while C and other languages use a semi-colon. Here is a COBOL example: 


EXEC SQL 
SELECT EMPNO, LASTNAME 
INTO :EMPNO, :LASTNAME 
FROM EMP 

END-EXEC. 


In this example, EMPNO and LASTNAME are retrieved into host variables which are 
preceded by a colon. Host variables (HV) are variables defined in the “host” language 
(COBOL, PL/I, etc....), the language that embeds the SQL. During the DCLGEN phase, 
a set of those variables are also defined. The HV name is here the same as the column 
name, which is not a requirement, it can be any name with a compatible datatype, to the 
columns datatype. 


After the precompile, our program is divided into 2 parts: 


> the modified source code; this is the original source code, were the SQL is 
commented out and replaced by Calls 


> database request module (DBRM), which is usually a member of a PDS library and 
contains the SQL statements of the program. 


The modified source code is passed on to the compiler to be compiled and linkedited to 
create an executable load module, just like any program which does not contain SQL. 
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By the way, you can embed any type of SQL into your program; DML, DDL and DCL, 
as long as the authorization rules are respected. 


Compile 


! 


‘es, DCLGEN 


| | 


Source 
Program 







Precompile 





Include 
Member 


Kage 





Linkedit 


Figure 14-8 Program Preparation flow 


BIND 


BIND can be thought of as the DB2 equivalent compile process for the DBRM. Bind 
does three things: 


1. checks your syntax for errors 

2. checks authorization 

3. and most importantly, determines the access paths for your statements. DB2 has a 
component called the optimizer, which assesses all the different ways that your data 
can be accessed, such as scanning an entire table, using an index, what index, etc.... 
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It weighs the costs of each and picks the least. It is referred to as a cost-based 
optimizer (as opposed to a rule-based optimizer). 


The SQL with its access path (and the consistency token/timestamp) is stored as a 
package in a DB2 directory. Other information, such as package information and the 
actual SQL, is stored in the catalog. The bind creates the executable SQL code for one 
application in a package. Now DB2 has all the information he needs, to get to the 
requested data for this program. 


Often programs are calling subroutines, which will also contain SQL calls. Each of those 
subroutines will than also have a package. You need to group all of the DB2 information 
together. Therefor we need another step: another bind, but this time to create a plan. 


Even if you are not using a subroutine, you still need to create a plan. The plan may 
contain more information than only your program info, you can even create them generic. 
That is common practice: the plan contains all packages of | project and every run uses 
the same plan. 


To be complete, we need to add that originally the DBRMs were bind strait into the plan 
(they are called instream DBRMs). However if there is one small change to one of the 
programs, you need to rebind the whole plan. The same when an index is added. 


During this binding process, as you know, DB2 updates its directory and catalog. Update 
means avoiding that other people can update (data is locked from them), so most other 
actions towards DB2 were nearly impossible. To avoid this constraint, packages were 
introduced, now you only need to rebind the one package, so the duration of the update is 
very small, impact on other users is almost zero. There are still plans around with 
instream DBRMs, although most companies choose to convert them into packages. 


Plans are unique to the mainframe environment. Other platforms do not use them. 


RUN 


When you execute your application program, the load module is loaded into main 
storage. When an SQL statement is encountered, the CALL to DB2, which replaced the 
SQL statement, passes its parameters to DB2. One of those is the consistency token. This 
token, or timestamp, is also in the package. The packages in the specified plan of DB2 
are then searched for the corresponding timestamp, and the appropriate package is loaded 
and executed. So, at the run, you need to specify the plan name as a parameter. 


One last note: the result of an SQL statement is usually a result-set (more than one row). 
An application program can only deal with one record/row at a time. There is a special 
construction added to DB2, called a cursor (essentially a pointer), which allows you in 
your embedded SQL to fetch/update/delete one row at a time, from your result set. 


To know more about application programming we refer to the DB2 UDB for z/OS: 
Application Programming and SQL Guide. 
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14.5.2 Get the access path with EXPLAIN 


If you want to find out what access path the optimizer has chosen or if you want to test 
your SQL to see how expensive it is before you use it in an application program, you can 
use an EXPLAIN statement. This looks like an SQL statement and can be executed in 
SPUFI: 


EXPLAIN ALL SET QUERYNO = 1 
SELECT EMPNO, LASTNAME 

FROM EMP 

WHERE LASTNAME = 'MILLER'; 


The SQL is not executed when you run this statement. Instead, EXPLAIN populates a 
special table, called a PLAN TABLE, with one or more rows describing your access 
path. Each user must have a PLAN TABLE to do this. You can then do a SELECT 
against this table to interpret the access path: 


SELECT * 
FROM PLAN_TABLE 
WHERE QUERYNO = 1; 


If the EMP table were very big, the SELECT query would probably execute faster if 
there were an index on LASTNAME. Reading the entire table would be more expensive 
when you only want a few rows. You can look at the column, ACCESSTYPE, in your 
PLAN_TABLE to see if an index or a table scan was used. If the value is I, then an index 
was used. If the value is R, a scan was used, possibly because there is no index on the 
table. 


Reading entries ina PLAN_ TABLE requires interpreting the recorded values in terms of 
good and bad access paths. More information can be found in Performance books on 
DB2 e.g. IBM DB2 Performance Expert for z/OS Version 2. 


14.5.3 OTHER DEVELOPMENT OPTIONS 
ODBC 


Open Database Connectivity is an application interface that uses function calls to pass 
dynamic SQL statements as function arguments. ODBC for DB2 is designed to be used 
by C and C++ programs and can be used to make calls to DB2 instead of using embedded 
SQL. When ODBC is used, a specific set of function calls is used at runtime to execute 
SQL statements and access the database. A precompile is not necessary since all SQL is 
passed as a parameter in a CALL statement. 


JAVA 


Java lets you write portable application programs that are independent of any one 
database product. In fact, a Java program is designed to be able to run regardless of the 
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machine and operating system. This platform independence is achieved through the use 
of byte codes which are machine-independent. A program is compiled into byte codes 
and then processed by the Java Virtual Machine (JVM), which interprets the byte codes 
for the particular platform. Java provides two options for accessing DB2 for z/OS. 


SQLJ 


SQLJ application support lets you write static SQL applications in Java. With SQLJ, you 
can embed SQL statements in Java applications, and the applications are precompiled, 
compiled and bound. 


JDBC 


JDBC application interface lets you write dynamic SQL applications in Java. JDBC is 
similar to ODBC but is designed specifically for use with Java. JDBC applications do not 
require precompiles or binds. 


XML 


Extensible Markup Language (XML) enables the definition, transmission, validation, 
and interpretation of data between applications and organizations. XML is similar to 
HTML in its use of tags. However, XML is used to describe data rather than how data 
appears on a Web page. It allows users to define their own tags. Organizations use XML 
for document processing and for publishing information on the Web. When you store or 
create a document, you can use the capabilities of the DB2 XML extender, which 
provides data types, functions and tools to help integrate XML with DB2. 


XML Column Access 


XML access methods include a column access method which stores and retrieves XML 
documents as column data. In other words, an entire XML document can be stored in a 
single DB2 column defined as an XMLCLOB. 


XML Collection Access 

Another access method is the collection access method which creates or composes XML 
documents from DB2 tables and columns. It can also decompose XML documents into 
DB2 tables and columns. 


14.6 Managing DB2 
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Managing DB2 falls into two categories: 
1. system administration, usually performed by a DB2 system programmer (SYSADM) 
2. database administration, performed by the DB2 database administrator (DBA). 
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In small shops these two categories can be performed by one person, the DBA. However, 
most companies will have both a system person as well as a DBA. 


14.6.1 System Administration 


System administration involves having knowledge of DB2 as well as the z/OS 
environment and how the two interface. Certain z/OS parameters can override 
corresponding DB2 settings. 


Installation 


The system administrator installs the DB2 subsystem and through a series of panels sets 
up system parameters called DSNZPARMS or ZPARMS for short. 


These parameters set up limits that control the DB2 environment, such as the number of 
log data sets and the maximum number of connections. Most of these can be changed 
later for performance reasons. After the installation of DB2, the system administrator will 
periodically install maintenance releases to update the database subsystem as well as fix 
problems. 


System Object Management 

The system administrator is responsible for system structures such as_ the 
catalog/directory, buffer pools and the log data sets. It is sometimes necessary to 
reorganize the data in the catalogs, to add another buffer pool or reassign buffer pools, or 
to make log data sets larger or increase their number. The system person sets up 
connections with other subsystems, handles external security, administers DB2 storage 
devices, and manages the communication database for DDF. 


System administrators are given a special group authorization, called SYSADM. This 
collective authorization gives the administrator control over and access to the entire DB2 
subsystem. 


System and Disaster Recovery 


The system administrator gets involved with DB2 system recovery which usually 
involves stopping the DB2 subsystem and restarting it. This position is also responsible 
for setting up and testing disaster recovery plans. This involves bringing up the DB2 
subsystem at a completely different site because the original environment has been 
destroyed. 


Monitoring System Performance 

On a day-by-day basis, the system administrator monitors the DB2 subsystem using a 
performance monitor tool such as Omegamon or DB2PM (DB2 Performance Monitor). 
These tools provide information on the system objects as well as application information. 
There are also performance reports that these tools provide for SQL or locking problems. 
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The administrator needs to become familiar with the subsystem and its workload patterns 
to be able to ascertain performance discrepancies. Workloads will change from online 
applications activities in the daytime to batch activities at night and from week day to 
weekend. 


14.6.2 Database Administration 
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Database administrators are primarily responsible for specific databases in the 
subsystem. 


In some companies, DBAs are given the special group authorization, SYSADM, which 
gives them the ability to do almost everything in the DB2 subsystem and gives them 
jurisdiction over all the databases in the subsystem. In other shops, a DBA's authority, 
through the DBADM authority, is limited to individual databases. 


Creation/Management of DB2 Objects 

The DBA creates the hierarchy of DB2 objects, beginning with the database, then table 
spaces, tables, and any indexes or views that are required. He also sets up the referential 
integrity definitions and any necessary constraints. 


The DBA essentially implements the physical database design. Part of this involves 
having to do space calculations and determining how large to make the physical data sets 
for the table spaces and index spaces, and assigning stogroups. 


There are many tools that can assist the DBA in these tasks, such as the Administration 
Tool and DB2 Estimator. If objects increase in size, the DBA is able to alter certain 
objects to make changes. 


The DBA can be responsible for granting authorizations to the database objects although 
sometimes there is a special security administration group that does this. 


Utilities 

The DBA maintains the database objects by using a set of utilities and programs which 
are submitted using JCL jobs. Usually a company will have a data set library for these 
jobs that DBAs copy and use. However, there are tools that will generate the JCL, such as 
the Administration Tool and the Utility option on the DB2I panel. 


The utilities help the DBA in doing his/her job. You could divide the utilities into 
different categories: 


Data Organization utilities 

Once tables are created, the DBA uses the LOAD utility to populate them with the ability 
to compress large amounts of data. There is the Unload utility or the DSNTIAUL 
assembler program that can let the DBA move or copy data from one subsystem to 
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another. It is possible to keep the data in a certain order with the REORG utility. 
Subsequent insertions and loads can disturb this order, and the DBA must schedule 
subsequent REORGs based on reports from the RUNSTATS utility, which provides 
statistics and performance information. 


Backup and Recovery utilities 

It is vital that a DBA take image copies of the data and the indexes with the COPY utility 
in order to recover data. A DBA can take a full copy or an incremental copy (only for 
data). Since recovery can only be done to a full copy, the MERGECOPY utility is used to 
merge incremental copies with a full one. The RECOVER utility can recover back to an 
image copy for a point-in-time recovery. More often, it is used to recover to an image 
copy, and then information from the logs, which record all data changes, is applied in 
order to recover forward to a current time. Without an image copy, an index can be 
recreated with REBUILD INDEX. 


Data Consistency utilities 


One of the important data consistency utilities is the CHECK utility which can be used to 
check and help correct referential integrity and constraint inconsistencies, specially after 
an additional population or after a recovery. 


Commands 

Both the system administrator and DBA use DB2 commands to monitor the subsystem. 
The DB2I panel and the Administration Tool provide you with a means to easily enter 
these commands. The -DISPLAY DATABASE command will display the status of all 
table spaces and index spaces within a database. For example, without an image copy, 
your table can be put in a copy pending status, requiring that you run the COPY utility. 
There are several other display commands such as DISPLAY UTILITY for the status of a 
utility job, or you can display buffer pool, thread, and log information. 


There are also DSN commands that you can issue from a TSO session or batch job. 
However, these can be more simply entered using the options from the DB2I panel: 
BIND, DCLGEN, RUN, etc. (In some shops, DBAs are responsible for binds although 
they are usually done by programmers as part of the compile job.) 


14.7 Summary 


The relational database is the predominant approach to data organization in today's 
business world. IBM's DB2 was developed according to the rules set down by Dr. E. F. 
Codd, who created the relational model. Because of this, DB2 implements such relational 
principles as primary keys, referential integrity, a language to access the database (SQL), 
nulls, and normalized design. As a relational database, the most fundamental structure is 
the table with columns and rows. 
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There is a hierarchical dependency to the basic objects in DB2. The table structure can 
have indexes and views created on it. If a table is removed, these objects also get 
removed. Tables are contained in a physical data set called the table space, and the table 
space is associated with a database which is a logical grouping of table spaces. Newer 
schema objects in DB2 include UDTs, UDFs, LOBs, triggers, and stored procedures. 


DB2 also has system structures which help to manage the subsystem. The catalog and 
directory keep metadata about all the objects in the RDBMS. Buffer pools are used to 
hold pages of data from disk storage for faster retrieval; the active/archive logs and the 
BSDS are a way for DB2 to record all the changes made to the data for recovery 
purposes. 


The only way to access the data in DB2 databases is with SQL. It is not a full 
programming language, and it works at the set level, using a result table when it 
manipulates data. SQL has three categories based on functionality: DML, DDL, and 
DCL. On the mainframe, SPUFI is a tool used to enter SQL statements. 


There are some special steps needed to use SQL in application programs since traditional 
3GL compilers do not recognize SQL. The precompiler comments out SQL statements in 
a program, copies them to a DBRM with a consistency token, and replaces them with 
calls to DB2. The modified source code is then compiled and linkedited. The DBRM 
goes through a bind process which determines the access path and stores this executable 
SQL code in a package. Packages are then logically associated with a plan. When run, the 
call to DB2 in the load module passes its consistency token to DB2 to be matched to its 
twin in the appropriate plan in order to execute the SQL. 


SQL can handle both static and dynamic statements, and EXPLAIN can be used to find 
out what access path the optimizer chose for the SQL. There are other development 
options. ODBC can pass SQL statements as parameters of function calls and thus bypass 
the precompile process. 


Java can handle static SQL with SQLJ, which uses the traditional precompile/bind 
process, and dynamic SQL with JDBC, which does not use this process at all. Lastly, 
XML can be used to retrieve and store documents in the database subsystem. 


There are two areas of DB2 management: system administration and database 
administration. 
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14.8 Discussion questions 


te a 


10. 


1 


— 


What DB2 objects define a physical storage area? Does a table? 
What are some of the problems with the following SQL statement? 


SELECT * 
FROM PAYROLL; 


What category of SQL would you use to define objects to DB2? 

What are the three main address spaces that DB2 uses? What do they handle? 
Describe the program preparation process, using Figure 14-8 on page 14-15. 
How does the precompiler find an SQL statement in a program? 

How does a load module get put back together with the SQL statements? 


How could you find out what access path the optimizer chose? What process creates 
this path? 


What is a stored procedure? 


Can DB2 work with XML? If so, how? 


. What are some of the responsibilities of a system administrator? 
12. 
13. 


What are some of the responsibilities of a database administrator (DBA)? 


What are some of the ways that security is handled by DB2? 


14.9 Exercises 


The exercise will be on the use of SPUFI and should result in a working COBOL-DB2 
program. 
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14.9.1 Step 1: Create files 


Before you start with the real DB2 exercise, you need to create two more PDSs: 
> ZUSER##.DB2.INCLUDE: to store your DCLgens 
> ZUSER##.DB2.DBRM: to store your DBRMs 


You can use the ZUSER##.LANG.CNTL as base. 


Furthermore, you also need a ZUSER##.SPUFI.OUTPUT file, which should be a flat file 
of the record format VB, with a record length of 4092, Block length 4096. 


14.9.2 Step 2: DCLGEN 
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A DCLGEN is an easy way to automatically generate COBOL definition statements for 
the DB2 information that you use in an application program. These statements are then 
included in the source program. 


First, from the DB2I (DB2 Interactive) menu, choose D for DB2I Defaults (Figure 14-9) 
and hit enter: 





DB2I PRIMARY OPTION MENU SSID: DB8H 

COMMAND ===> D_ 
Select one of the following DB2 functions and press ENTER. 

1 SPUFI (Process SQL statements) 

2 DCLGEN (Generate SQL and source language declarations) 

3 PROGRAM PREPARATION (Prepare a DB2 application program to run) 

4 PRECOMPILE (Invoke DB2 precompiler) 

5 BIND/REBIND/FREE (BIND, REBIND, or FREE plans or packages) 

6 RUN (RUN an SQL program) 

7 DB2 COMMANDS (Issue DB2 commands) 

8 UTILITIES (Invoke DB2 utilities) 

D ODB2I DEFAULTS (Set global parameters) 

Xx EXIT (Leave DB2I) 

F1=HELP F2=SPLIT F3=END F4=RETURN F5=RFIND F6=RCHANGE 
F7=UP F8=DOWN F9=SWAP F10=LEFT F11=RIGHT F12=RETRIEVE 

















Figure 14-9 DB2I Menu 


On the DB2I Defaults Panel 1, specify IBMCOB for option 3 Application 
Language(Figure 14-10 on page 14-25). 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter14 DB2.fm 














DB2I DEFAULTS PANEL 1 
COMMAND ===> _ 
Change defaults as desired: 
dt DBZ NAME 6 cca ais tmoaave ===> m identifier) 
2 DB2 CONNECTION RETRIES ===> many retries for DB2 connection) 
3 APPLICATION LANGUAGE ===> (ASM. C. CPP. IBMCOB. FORTRAN. PLI) 
4 LINES/PAGE OF LISTING ===> (A number from 5 to 999) 
S. MESSAGE LEVEL» ss.cccaacrs ===> (Information, Warning. Error. Severe) 
6 SOL STRING DELIMITER ===> (DEFAULT. * or “) 
? DECIMAL POINT ........ ===> (. OF sl 
8 STOP IF RETURN CODE >= ===> (Lowest terminating return code) 
9 NUMBER OF ROWS ....... ===> (For ISPF Tables) 
10 CHANGE HELP BOOK NAMES?===> (YES to change HELP data set names) 
F1=HELP F2=SPLIT F3=END F4=RETURN FS=RFIND F6=RCHANGE 
F7=UP F8=DOWN F9=SWAP F1iO=LEFT F1i1=RIGHT F12=RETRIEVE 














Figure 14-10 DB2I Default panel 1 


Hit enter, and on DB2I Defaults Panel 2, specify DEFAULT for the COBOL string 
delimiter under option 2 and G for the DBCS symbol for DCLGEN for option 3. Hit 
enter.(Figure 14-11) 





DB2I DEFAULTS PANEL 2 
COMMAND ===> 


Change defaults as desired: 


1 DB2I JOB STATEMENT: (Optional if your site has a SUBMIT exit) 





COBOL DEFAULTS: 


COBOL STRING DELIMITER ===> DEFAULT, ° or “) 
DBCS SYMBOL FOR DCLGEN ===> (G/N - Character in PIC clause) 


=, 


F1=HELP F2=SPLIT FS3=END F4=RETURN FS=RFIND F6=RCHANGE 
F7=UP F8=DOWN F9=SWAP F1Q0=LEFT F11=RIGHT F12=RETRIEVE 


Figure 14-11 DB2I Default panel 2 











This is just to make sure that you have the correct language... 


After that enter, you are back on the main DB2I panel (Figure 14-9 on page 14-24); now 
you select option 2 DCLGEN. 
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You will need to have a destination data set already allocated to hold your DCLGEN 
definition (ZUSER##.DB2.INCLUDE), it should be created for you. If you do not have 
one, go to the ISPF menu and create a PDS file. 











DCLGEN SSID: DB8H 
===> 
Enter table name for which tect oragig Oe ired 
1 SOURCE TABLE NAME ===> emp —_ 
2 TABLE OWNER .. . ===>) DSNSs10 
3 “AT LOCATION <...: ===> Btional) 
Enter destination data set (Can be sequential g¢ "titioned) 
4 DATA SET NAME ===> 'ZUSERH#H#.DB2. INCLUDE (DCLEMP) ' 
So DATA SET P NORD ===> Gi password protected) 
Enter options 2sired: >a 
© “ACTION: so0sc5522% > ADD (ADD new or REPLACE old declaration) 
¢ COLUMN LABEL is > NO (Enter YES for column Label) 
8 STRUCTURE NAME ===) (Optional) 
9 FIELD NAME PREFIX > (Optional) 
10 DELIMIT DBCS . ===> YES (Enter YES to delimit DBCS identifiers) 
11 COLUMN SUFFIX ; ===> NO (Enter YES to append column name) 
12 INDICATOR VARS ===> 0a (Enter YES for indicator variables) 
13. RIGHT MARGIN . ===>)972 (Enter 72 or 80) 
F1i=HELP F2=SPLIT F3=END F4=RETURN FS=RFIND F6=RCHANGE 
F7=UP F8=DOWN F9=SWAP F10=LEFT F11=RIGHT F1i2=RETRIEVE 














Figure 14-12 DCLGEN 


As Figure 14-12 shows, you need to specify, the table, the table owner, you PDS file and 
the action ADD. The result should give: 


In case the definition of the table changes, you need to change also the DCLGEN. The 
action would than be REPLACE. 


14.9.3 Step 3: Test your SQL 
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Go to SPUFI, use your SPUFI.CNTL PDS. In that PDS you find a member ‘SELECT’, 
this is the SQL statement you will use in your program, the where-clause is not there, so 
that you can see all the result you can get. It also gives you the opportunity to know what 
departments are available in the table. 


Surely for more complex queries, this is common practice, as an application developer 
you are sure to execute the right SQL. 
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14.9.4 Step 4: Complete the program 


Now you are ready to ‘create’ a program. Because this is not a programming class, the 
program is prepared for you. It is in LANGSOURCE(COBDB2). The program calculates 
the average salary for one department. You specify the department and you get the result. 
To end the program, you need to enter ‘999’. 

In this program you need to fill out two things: 

> your variables (include the member you have created in step 1) 

> specify the SQL delimiters for COBOL 


If you search for ‘???’ you will find the spots. 


14.9.5 Step 5: Complete the program 
Go to your LANG.CNTL(COBDB2) job and perform the changes stated at the top of the 
job. 
You find different steps in this job: 


> Step PC: is the DB2 Precompile; this will split your source into two part: the DBRM 
and the modified source 


> Steps COB, PLKED and LKED: do the compile and linking of your modified source 
> Step BIND: does the bind of the package and the plan. 


Question: If you needed to change your program, which bind could be left out? Fee 
free to change the program, in stead of the average, you can ask the minimum or 
maximum salary within a department (than you just need to change the SQL). 


> Step Run: runs the program in batch for two departments: A00 and D21. 


14.9.6 Step 6: Run the program from a TSO screen 


In stead of running you program in batch, you could run it from your screen. Therefor 
you need to allocate both files to your session. This has to be executed before you start 
with the run. 

So you need to type the following (hit enter after each line): 

TSO alloc da(*) f(sysprint) reuse 


tso alloc da(*) f(sysin) reuse 


Than (or before) you can go back to you DB2I screen. 
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Select option 6 RUN. Here you have to fill in your filename and your plan name 
(Figure 14-13): 





1 


8 gen SSID: DB8H 
===> tso alloc da(«*) f(sysprint) reuse 2 


Enter the name of the program you want to run: 
1 DATA SET 
2 PASSWORD 3; .. (Required if data set is password protected) 





Enter the following as desired: 2 

3 PARAMETERS 

4 PLAN NAME .. =) (Required if different from program name) 
5 WHERE TO RUN (FOREGROUND, BACKGROUND, or EDITJCL) 


F1=HELP F2=SPLIT F3=END F4=RETURN FS=RFIND F6=RCHANGE 
F7=UP. F8=DOWN F9=SWAP FIQ=LEFT FI2=RIGHT Fi2=RETRIEVE 











Figure 14-13 Ready to execute 





AG1 


AGO 


D21 


D1i1 


999 








Figure 14-14 The execution of the program 
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14.10 Instructor Notes 


You need to create an output file for SPUFI, best prior to the class, or you can show the 
students again how to do it, because they need to do it as well... You need a 
ZPROF .SPUFI.OUTPUT file, VB with record length of 4092, block length 4096, 10 
tracks should be enough. 


14.10.1 refer to 14.2.1, “Data Structures” on page 14-2 


We did not want to take about the different table spaces (TS); you have 3: 


> Simple TS, which are good if you have only 1 table/TS; but it is not really advised to 
used them anymore. Actually they are kept alive because some of the catalog tables 
are in simple TS 

> segmented TS, which only allows info of 1 table into 1 segment and after reorg all the 
segments of the same table are grouped together 

> partitioned TX: for very large tables, each partition has its own data set, which is the 
same of the partitioning index. So you define in the index what is coming in which 
partition 


go into the HLQ (high level qualifier) or owner of the objects, because this is not 
supposed to be a DB2 course. Mainly, at the creation you can specify who the owner of 
the objects will be; if you don’t specify it, it is you (the current userid). 


14.10.2 refer to 14.2.2, “Schema structures” on page 14-3 


We did not want to go into the HLQ (high level qualifier) or owner of the objects, 
because this is not supposed to be a DB2 course. Mainly, at the creation you can specify 
who the owner of the objects will be; if you don’t specify it, it is you (the current userid). 


A SCHEMA is a qualifier used for UDT, UDF, Stored procedures and Triggers, the 
related objects should have the same schema. SYSIBM is the default one; the special 
register CURRENT SQLID gives the current schema. Access can be granted on schema 
level. 


UDT: are datatype that are created on existing datatype. 


UDF are functions based on existing functions, you could create a function to convert 
between EURO and USD, if you assume a fixed rate. That way you are able to compare 
UDT. 


Triggers can be very useful for distributed data, or when you denormalized a table, to be 
sure that both tables are kept in sync. Sometimes it is also used to store some statistical 
info like averages, etc.... in separate tables, or some calculation which needs to be done a 
lot or by a lot of programs. 
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LOBs have been added to the mainframe, but so far its not so much used. It is mainly to 
be in sync with the other DB2 versions, like unix, windows, etc.... 


14.10.3 refer to 14.3.1, “DB2 Address Spaces” on page 14-6: 
Distributed Data 
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A DBMS, whether local or remote, is known to your DB2 subsystem by its location 
name. Remote systems can use this location name to access DB2. The location name and 
the network address of a remote DBMS (RDMS) are defined in the communications 
database (CDB), a set of tables in the DB2 catalog that have been created in the SYSDDF 
table space. DDF or the Distributed Data Facility is required for accessing distributed 
data through DB2. (You might recall that DDF is an optional address space.) DDF uses 
the information in the communications database to implement distributed data access. 


DRDA 


The primary method that DB2 uses for accessing data at a remote server is based on 
Distributed Relational Database Architecture (DRDA). DRDA is a set of protocols, or 
tules, that enable a user to access distributed data regardless of where it physically 
resides. DRDA just defines the rules; it does not provide the application programming 
interfaces (APIs) to perform the access. 


SQL IMPLEMENTATION 


You can write SQL statements like the following in a program to access data at a remote 
site. 


EXEC SQL CONNECT TO MIAMI; 
EXEC SQL 

SELECT * FROM PROD.EMP 
WHERE EMPNO = '000030'; 
EXEC SQL CONNECT TO BOSTON; 
EXEC SQL 

SELECT * FROM PROD. PROJ 
WHERE RESPEMP = '000030'; 


Another way to do this is to use a three-part name. However, this is only supported for 
mainframe DB2. Notice that the connection cannot be explicitly requested, but is handled 
when the distributed request is initiated. 


EXEC SQL 

SELECT * FROM MIAMI.PROD.EMP 
WHERE EMPNO = '000030'; 

EXEC SQL 

SELECT * FROM BOSTON.PROD. PROJ 
WHERE RESPEMP = '000030'; 
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In order to execute these statements, the DBRM that contains them must be bound at 
each remote site into a package. All remote packages are then bound into a plan, which 
also has a local bound package, at the local site. 


There are essentially four levels of DRDA implementation: 


1. Remote request - supports only one SQL statement per single remote DBMS within a 
unit of work (commit). 


2. Remote Unit of Work - supports multiple SQL statements per one RDBMS within a 
unit of work. 


3. Distributed Unit of Work - more than one RDBMS can be accessed per unit of work. 
However, only one RDBMS can be specified per SQL statement. The examples given 
above use DUW. 


4. Distributed Request - a single SQL statement can access multiple RDBMS. An 
example of this is a join that accessed one table in one location and another table in 
another. No RDBMS products implement this. 


DB2 CONNECT 


DB2 Connect allows applications that run in a Linux/Unix/Windows environment to 
access mainframe DB2 data. In fact, DB2 Connect provides transparent read/write access 
to all DB2 servers, not just z/OS. In conjunction with DB2 Relational Connect, it also 
provides access to 


Informix and non-IBM relational databases. DB2 Connect implements DRDA. 


14.10.4 refer to 14.4.1, “SPUFI” on page 14-8 


Some other things could be shown here, like accessing the catalog tables, creating a 
DCLGEN, doing the complete flow of a program. 


You could actually spend a whole lesson here, but we doubt the added value. The hole is 
to see a way of accessing the DB2 data/executing SQL. 


QMF is not shown, because it is not part of the standard platform. If you have it, you 
could show some reporting features, to show that you can do nearly everything as with 
MSaccess.... 


14.10.5 refer to 14.5, “Application Programming” on page 14-13 


we could go much more into detail into the program itself, but if they know what a host 
variable is, how to use SQL in a program, we think that this is OK. You can go deeper 
into the use of a cursor. Just to indicate it to you, this is how that works: 
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Use a cursor in an application program to retrieve rows from a table or from a result set 
that is returned by a stored procedure. This part explains how your application program 
can use a cursor to retrieve rows from a table. 


When you execute a SELECT statement, you retrieve a set of rows. That set of rows is 
called the result table of the SELECT statement. In an application program, you can use 
either of the following types of cursors to retrieve rows from a result table: 


- A row-positioned cursor retrieves at most a single row at a time from the result table 
into host variables. At any point in time, the cursor is positioned on at most a single row. 


- A rowset-positioned cursor retrieves zero, one, or more rows at a time, as a rowset, 
from the result table into host variable arrays. At any point in time, the cursor can be 
positioned on a rowset. You can reference all of the rows in the rowset, or only one row 
in the rowset, when you use a positioned DELETE or positioned UPDATE statement. 


Accessing data by using a row-positioned cursor 
The basic steps in using a row-positioned cursor are: 


1. Execute a DECLARE CURSOR statement to define the result table on which the 
cursor operates. 


2. Execute an OPEN CURSOR to make the cursor available to the application. 
3. Specify what the program is to do when all rows have been retrieved. 


4. Execute multiple SQL statements to retrieve data from the table or modify selected 
rows of the table. 


5. Execute a CLOSE CURSOR statement to make the cursor unavailable to the 
application. 


Your program can have several cursors, each of which performs the previous steps. 


14.10.6 refer to 14.6.2, “Database Administration” on page 14-20 
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It may be important to state that the DBA needs to runs runstats to get the statistics 
up-to-date. Otherwhise you can not have any good performance, since DB2 uses his 
statistics to determinate what access path to use. On the other hand, developers should 
also learn to use explain. It they than see that an index is not used, where is should be to 
there opinion, they should contact the DBA. 


Utilities commonly used by a DBA include LOAD, CHECK DATA, RUNSTATS, 
REORG., COPY. A combination of most of them is possible in one run. For details, see 
the utilities guide. 
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14.10.7 no refer, good to know in case of questions: data sharing 


Data sharing is an optional feature that can be set up to allow applications running on 
multiple DB2 subsystems to concurrently read and write (i.e., share) the same data sets. 
DB2 subsystems that share data belong to a DB2 data sharing group, and there can be up 
to 32 subsystems in one group. 


Data sharing involves a Parallel Sysplex, which is a cluster of z/OS systems that 
communicate and cooperate with each other. This sysplex requires two items. 


1. A coupling facility is necessary to provide communication among the members in 
order to coordinate locking and buffer pool information. 


2. A-sysplex timer is also necessary to provide a common time source in order to 
coordinate log records on all the systems. 


Data sharing is a complex implementation but has several benefits. 


Data sharing improves data availability. If one subsystem goes down, users can access 
their DB2 data from another subsystem. Transaction managers are informed that DB2 
is down and can switch new user work to another DB2 subsystem in the group. 


Another benefit is expanded capacity. Capacity can be increased during heavy work 
peaks, such as end-of-quarter processing, by adding new members and then cutting 
back during normal schedules. 


Data sharing provides scalable growth. A Parallel Sysplex cluster can grow 
incrementally. DB2 subsystems can be added to handle increasing workloads. 


14.10.8 refer to 14.8, “Discussion questions” on page 14-23: Answers 


1. What DB2 objects define a physical storage area? Does a table? 


Table spaces (TS) and Index spaces define the storage; for BLOBs we also have 
auxiliary table spaces, but they are not discussed during the course. 


A table is placed in the TS, so you don’t define the space there. 
2. What are some of the problems with the following SQL statement? 


SELECT * 
FROM PAYROLL; 


There is no real problem with the statement but... 
- You will get all the columns and rows back, and do you really need them? 


- if you embed this and the definition of the table changes and the package gets a 
rebind (which happens!), the program may fail there aren’t enough HV. 


- if this is a large table, the execution will result in a TS scan, which may take a lot of 
time. 
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- if executed in SPUFI, maybe not all the result rows will be executed 


- there is no qualifier to the table, so are you sure you have the right one? This is not 
really discussed, but you may get questions on that. 


3. What category of SQL would you use to define objects to DB2? 
The DDL; Data Definition Language 

4. What are the three main address spaces that DB2 uses? What do they handle? 
— System services address space (SSAS) 


This address space is responsible for all logging activities, recovery, and 
coordinates the attachment of DB2 to other subsystems, such as TSO, CICS, or 
IMS/TM. DSNMSTR is the started task that contains the DB2 log. 


— Database Services Address Space (DBAS) 
This address space is responsible for the manipulation of DB2 data structures. 
— Internal Resource Lock Manager (IRLM) 
This address space is responsible for locking. 
5. Describe the program preparation process, using Figure 14-8 on page 14-15. 


This is the complete explanation as you find it in 14.5.1, “DB2 Program Preparation: 
the flow” on page 14-13. 


6. How does the precompiler find an SQL statement in a program? 


They all start with “EXEC SQL” and they end with a program language specific 
delimiter. 


7. How does a load module get put back together with the SQL statements? 
At the run, you need to specify the plan to use. 


8. How could you find out what access path the optimizer chose? What process creates 
this path? 


Via an EXPLAIN (can be executed on a program, you will than get every SQL 
statement explained). 


For static programs it is determinated at the bind of the packages, Therefor a DBA 
may decided to rebind the packages after adding/removing an index, because 
otherwhise it may have a big impact on the performance of the program. Note that 
after de delete and recreate of a table (which you normally would NOT do, since you 
also have to keep the data), the package gets an automatical rebind. To get a good 
access path, it is also important that the DBA make sure that the runstats utility has 
run on the tables, because that stores the figures in the catalog tables, which are used 
to determinate the access path. 
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For dynamic programs, the access path gets (more or less) regenerated at EACH 
execution (which will be must more expensive, of course). 


9. What is a stored procedure? 


A stored procedure is a user-written application program that typically is stored and 
run on the server (but it can be run for local purposes as well) 


10. Can DB2 work with XML? If so, how? 
Yes, via DB2 XML extender 
11. What are some of the responsibilities of a system administrator? 


Installation, system structures, system & disaster backup & recovery, monitoring the 
system, etc.... 


12. What are some of the responsibilities of a database administrator (DBA)? 


Creating objects, maintaining objects, executing utilities (to add data, to update the 
statistics in the catalog, to backup & recover the data, etc.), execute some commands 


13. What are some of the ways that security is handled by DB2? 
- grant / revoke on tables, via the DCL, set by the DBA 


- use on views, on which you should put the access. 


14.10.9 Answers to 14.9, “Exercises” on page 14-23 


Before they start they need to create 2 more PDSs, both will normally only contain one 
member unless they want to do some more programming. You do need to grant the 
student the needed authority, we did not test it, because we had no additional userid, but 
we think it is covered in ZPROF INST.CNTL(GRANTS). The additional exercises are in 
comment. Now for the exercise itself: 


During the exercises, students do 3 major actions: 
1. Create a DCLGEN 

2. Execute SQL via SPUFI 

3. Change and run a COBOL program 


The DCLGEN is strait forward; everything is explained well. An error may happen if 
they press twice enter, because the member than already exist. 


The SQL is completely in the ZUSER##.SPUFI.CNTL, but if they want, they can add 
(before the GROUP BY): WHERE WORKDEPT = ‘A00’, than they will only receive 1 
row back. 


Concerning the program, it is a simple program, reading only one row (to avoid that they 
have to work with cursors), so make sure that whatever SQL they use there, the result is 
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only 1 row. If not you get an error during the execution. You find a solution of the 
program in ZPROF.INST.CNTL(COBDB2). The JCL to use is COBDB2J; the DCLGEN 
is also there. 


If that does not work, you have the DBRM and the loadlib also in the same directory. So 
if you bind the DBRM (you can use the online screens of DB2I) in the package and you 
create a plan. The execution should also work. 


In the Class directories, you have the option to do some SQLs (this depends on the level 
of SQL know by the students), and an explain exercise. I provided the columns for a plan 
table in the SPUFIL.CNTL(PLANTAB),; you need of course a DB in which you can create 
the table. If you want the student to do so, you will need to give them access to create 
tables in a database as well. 
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15 


HTTP Server and WebSphere 
Application Server on z/OS 








Objective: This chapter explains the main difference of the HTTP Server 
versus the WebSphere Application Server. It also shows how to deploy a Web 
application on z/OS, with information on making use of the z/OS -specific 
Web enabling technologies, such as WebSphere Application Server on z/OS 
and the J2EE specification implementation through WebSphere. 


In this chapter, you will learn: 


> about the HTTP Server 
— Server modes 
— Static and Dynamic WebPages 
— server capabilities 
> about the WebSphere Application Server for z/OS 
— J2EE Application model 
— Modes to run the WAS 
— Connectors to CICS, DB2, IMS 
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Author Comment: Chapter was in Review by Rica Weller, and she said that the 
contents may not suite for our audience., and the chapter should be reworked (maybe 
with a higher focus on WebSphere Application Server) 


But due to our restricted timetable, we (Myriam, Rica, Michael) decided that it is a low 
priority to update this chapter. 
The update should be done for edition 2 of this Textbook 


Grossmann: Just added some easy exercises for the HTTP server, and some more 
discussion points 

Also, some information (performance, Host integration) put into the instructor Notes 
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Wayne comment: This chapter should explain how to deploy a Web application on z/OS, 
with information on making use of the z/OS -specific Web enabling technologies, such as 


WebSphere Application Server on z/OS and the J2EE specification implementation through 
WebSphere. 
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15.1 Introduction to Web applications on Z/OS 


As enterprises move to Web-enable most applications they have, some applications with 
strong mainframe ties tend to stay in the mainframe. IBM WebSphere Application Server 
for z/OS is a very popular choice as the agent of change for legacy applications. 


IBM WebSphere Application Server for z/OS (WAS) has strong back-end ties with 
legacy z/OS subsystems, such as CICS and DB2. It also interfaces well with WebSphere 
MQ for z/OS for enabling message queueing applications. The complexity of managing 
new subsystems that are becoming more critical over time and technology that is 
(mostly) unfamiliar to the z/OS system programming team introduces a significant 
friction in adopting IBM WebSphere Application Server for z/OS. 


WebSphere Application Server is an e-business application deployment environment. It 
is built on open, standards-based technology, such as CORBA, HTML, HTTP, IIOP, and 
J2EE-compliant Java technology standards for servlets, Java Server Pages technology 
(JSP), and Enterprise Java Beans (EJB), and supports all Java APIs needed for J2EE 
compliance. 


You can build and run mission-critical, object-oriented applications across an enterprise 
and beyond. You can conduct e-business over the Web because the Application Server 
supports multiple client platforms. You can even integrate new functions with existing 
z/OS applications and data. 


Applications and their components can be deployed globally on any 
WebSphere-supported server. It enables new e-business applications and transactions to 
be scaled up for deployment on the server of choice, regardless of the development 
platform. WebSphere continues to support connector access to CICS, IMS, and DB2. If 
you don’t need full J2EE support, you can configure WebSphere Application Server very 
simply without requiring the functions of LDAP, workload management goal mode, or 
DB2. In this case you can run your non-J2EE-compliant applications in the WebSphere 
plug-in that is loaded into the HTTP server. 


15.2 z/OS HTTP Server 


The HTTP server plays a central role in almost any e-business environment. z/OS HTTP 
Server provides static and dynamic web pages. The process receives an HTTP request 
and either serves a static file (like html pages or pictures), or redirects the request to an 
other component, which should handle it. This could be an external program connected 
via the Common Gateway Interface (CGD), or a program, that is connected via plugin. 
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If using WebSphere Application Server the HTTP Server is not necessarily needed, but 
there are several ways, how the HTTP Server may interact with WAS. These possibilities 
are mentioned in “Interaction with WebSphere” on page 15-6. 


The HTTP server has almost the same capabilities than most of the other HTTP servers, 
but it also has some features, that are z/OS-specific. These are discussed in 15.2.4, 
“HTTP server capabilities” on page 15-8. 


Documents related to the HTTP server are stored in the hierarchical file system (HFS) in 
the z/OS UNIX environment. A common place for this directory is /web. There are 
several subdirectories including configuration files and the documents provided by the 
HTTP server. There could also be several different configurations of the HTTP server, 
which may run on different ports in the same TCP/IP stack, or on different stacks. 


15.2.1 Server modes 


15-4 


There are three modes to run the IBM HTTP server in z/OS, in another words, there are 
three approaches that can be taken to enabling e-business on z/OS. Combined with WLM 
each approach can fit a particular business need. The Workload Manager is used to 
automatically scale the number of available servers and balance the workload between 
those servers (Refer to 17.2.2, “Workload Management” on page 17-4 to read more on 
WLM) 


Stand-alone server This mode is typically for HTTP server-only implementations, 
used for simple Web sites. Its main role is to provide a limited 
exposure to the Internet. 

WLM would not be used to classify requests by application 
environment specifications. A response time goal in terms of a 
time target and a velocity would balance all of the quantifiable 
elements such as CPU, storage, and I/O. 


Scalable server This mode is typically for interactive Web sites, where the 
traffic volume can decline and increase dynamically. It is also 
meant to be used in a more sophisticated environment where 
servlets and JSPs are invoked. 

In order for a system to scale, a queue manager with the ability 
to quantify work in terms that WLM understands, and to 
distribute the work in the same fashion, is necessary. 
WebSphere application server is designed with this particular 
goal in mind. 


Multiple servers This mode uses a combination of stand-alone and scalable 
servers to improve scalability and security throughout the 
system. For example, a stand-alone server could be used as a 
gateway to scalable servers. In this way the gateway could 
verify the user authentication of all requests, and reroute the 
request to the other servers. 
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An HTTP stand-alone server functioning as the gateway to scalable servers creates a 
barrier at which user authentication can be handled without exposing the entire system to 
unwanted eyes. The stand-alone server can provide URL rerouting (links) to other 
servers listening on different ports in the same TCP/IP stack, or on different stacks. User 
authentication at this point in the connection path permits the differentiation between 
Internet and intranet/extranet authorization and maintains the separation throughout the 
life of a connection. Although there is not true intranet/extranet implementation because 
there is no net, the same boundaries which are normally defined for these environments 
still exist in WLM and RACF. 


When designing a scalable system of any sort, it is best to keep the number of application 
environments to a minimum. Starting too many queue servers as a result of many 
application environments can have a negative impact on the system. Defining minor 
application environments with terms like fast, medium, and slow along with a separation 
of the major application between production and test is often a good place to start. By 
scaling the velocity of each category to accomplish a specified business goal, the impact 
is driven strictly by demand. A production or fast goal may cause the spawning of two or 
three queue servers for one application environment whereas test/fast may never have the 
need to spawn one. Setting reasonable limits for accomplishing goals is made easier by 
clearly-defined workload categories. 


15.2.2 Static Web pages 


The serving of static Web pages is almost the same as with other Web Servers. The user 
sends an HTTP request to the Web server to obtain a specific file. The Web server is the 
file in his file repository and sends it back to the user. When sending it back, it provides 
some information about this file (for example mime type and size) in the HTTP header. 


The HTTP server on z/OS has one major difference than compared with other Web 
Servers. Since z/OS systems store files in EBCDIC encoding, the documents have to get 
converted to ASCII, which is typically used in the Internet. Binary documents, like 
pictures, don’t have to get converted. Then using the HTTP server, you don’t have to take 
care of these conversions, because the HTTP server takes care of it. But you have to take 
care then you load documents to the server via ftp. If you specify ASCII as transport 
format, the file will get converted to EBCDIC. If you use binary, the file stays as it is. 


15.2.3 Dynamic Web pages 


Dynamic web pages are an essential part of the World Wide Web. Every kind of 
interaction and personalization requires dynamic content. For example, if a user fills out 
a form on a Web page, the data in this form usually needs to be processed and a feedback 
has to be sent to the user. 
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The Common Gateway Interface 


One possibility to provide dynamic Web pages is the Common Gateway Interface (CGD), 
which is part of the HTTP protocol. CGI is a standard way for a Web server of passing a 
Web user’s HTTP request to an application. This application generates the output and 
passes it back to the HTTP Server, which sends it back to the user via HTTP response. 
CGI is not limited to return HTML pages. The application may also create other things 
like plain text documents, XML documents, pictures or pdf documents. The mime type 
has to reflect the content of the HTTP response. 
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Figure 15-1 How the CGI works 


CGI has one major disadvantage. Each HTTP request requires a separate address space. 
This causes a lack of efficiency when there are many requests at a time. 


To avoid these performance problems, FastCGI has been created. Basically, FastCGI is a 
program that manages multiple CGI requests within a single address space. This saves 
many program instructions for each request. 


Interaction with WebSphere 


An other way of providing dynamic content is possible with help of the plugin interface 
provided by the HTTP server. Several products come as a plugin to the HTTP server, but 
there is one that is essentially important - the WebSphere Application Server. 


For passing through control to WebSphere, the WebSphere plugin is being used. There 
are several ways, how the HTTP Server may interact with WebSphere: 
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> WebSphere Plugin, same address space 
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Figure 15-2 Accessing Servlets using the WebSphere Plugin 


Figure 15-2 shows a simple configuration where no J2EE server is needed. This 
servlet may connect to CICS, IMS, or to DB2 via JDBC. It is not recommend to have 
business logic inside of servlets. 


> Web container inside HTTP Server, separate EJB container 





http:/Awww.myzseries.com/my.jsp nT Seer J2EE Server 


Client 


CICS Server 
Browser 


EJB or 
Container IMS Server 























Figure 15-3 Accessing EJBs from a WebSphere Plugin 
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15.2.4 HTTP server capabilities 


The HTTP Server provides nearly the same capabilities as any other Web Server, but 
some functionality mentioned here is z/OS-specific. The functions can be grouped into 


15-8 


Figure 15-3 shows a more usable configuration where the Servlets. The servlets run 
in another address space than the EJBs, so the EJBs are invoked via remote calls. The 
EJBs then gain information from other servers. 
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Figure 15-4 Accessing Servlets in a Web Container via the WebSphere Plugin 


In addition to running your servlets locally within the WebSphere Plugin, you can 
also use the WebSphere Plugin to run servlets remotely in a Web container. 
Figure 15-4 shows such a configuration. This allows you to localize your servlets and 


EJBs to the same z/OS address space, so that no remote EJB calls are required. 


three scopes. 


Basic functions 


> EBCDIC/ASCIH file access 


server access files and converts them, if needed, from EBCDIC to ASCII encoding. 


> SMF facilities 


As part of the z/OS features, the HTTP server can produce SMF records that can be 


retrieved later to do performance and usage analysis. 


> Tracing and logging 
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The HTTP server comes with a complete set of logging, tracing, and reporting 
capabilities that allow you to keep track of every HTTP request. 


> Server Side Includes (SSI) 


Server Side Includes allow you to insert information into documents, static or 
dynamic, that the server sends to the clients. This could be a variable (like the “Last 
modified” date), the output of a program, or the content of another file. This enabled, 
but not used, it can have a serious performance impact. 


> Simple Network Management Protocol (SNMP) MIB 


The HTTP server provides an SNMP Management Information Base (MIB) and 
SNMP subagent so you can use any SNMP-capable network management system, to 
monitor your server’s health, throughput, and activity. It can then notify you if 
specified threshold values are exceeded. 


> Cookies Support 


Since HTTP is a stateless protocol, a state might be added with the help of cookies, 
which store information on the client’s side. This is useful for a lot of Web pages, for 
example to achieve customized documents or for banner rotation. 


> Multi Format Processing 


This feature is used for personalization of Web pages. The browser sends header 
information along with the request, including the accept header. This information 
includes the language of the user. The HTTP server can make use of the contents of 
the accept header to select the appropriate document to return to the client. 


> Persistent connections 


With the help of this HTTP/1.1 specific feature, not every request has to establish a 
new connection. Persistent connections are staying “alive” during a certain amount of 
time to enable the use of this connection to another request. 


> Virtual hosts 


Virtual hosts allow you to run one Web server while making it appear to the clients as 
if you are running several. This is achieved by the use of different DNS names for the 
same IP and/or different IP addresses bound to the same HTTP server. 


Security functions 
> Thread level security 


An independent security environment can be set for each thread running in the HTTP 
server, which basically means that every client connecting to the server will have its 
own security environment. 


> HTTPS/SSL support 


The HTTP server has full support for the Secure Socket Layer (SSL) protocol. 
HTTPS uses SSL as a sub layer under the regular HTTP layer to encrypt and decrypt 
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HTTP requests and HTTP responses. HTTPS uses port 443 for serving instead of 
HTTP port 80. 


> LDAP support 


The Lightweight Data Access Protocol (LDAP) specifies a simplified way to retrieve 
information from an X.500-compliant directory in an asynchronous, client/server 
type of protocol 


> Certificate authentication 
As part of the SSL support, the HTTP server can use certificate authentication and act 
as a certificate authority. 

> Proxy support 


The HTTP server can act as a proxy server. You cannot, however, use the Fast 
Response Cache Accelerator (FRCA) 


File caching 

Performance can be significantly increased by using any of the following file caching 
possibilities: 

> HTTP server caching HFS files 


At HTTP server startup time, you can preload the frequently referenced HTML 
documents, pictures, and other Web files by using the CacheLocalFile directive. 


> HTTP server caching z/OS data sets 


Traditional z/OS data sets can also be cached through an option of the plugin that 
allows the HTTP server to access them. 


> z/OS UNIX caching HFS files 


newer releases of z/OS provide the possibility to cache selected read-only HFS files 
into the kernel address space with the help of the filecache command. Although this 
command is a function provided by z/OS UNIX, we can use this function to 
complement the HTTP server built with the CacheLocalFile directive. The filecache 
command can be used to cache DLL and CGI program executable. 


> Fast Response Cache Accelerator (FRCA) 


This is a cache mechanism automatically loaded during server operation. You are not 
required to list the files to be cached in your server configuration file. Dynamic 
content and protected pages are not cached. It is very fast because it uses the TCP/IP 
stack to cache the pages so that requests are handled without traversing the entire 
kernel or entering the user space. 
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15.3 WebSphere Application Server for z/OS 


WebSphere Application Server (WAS) is a comprehensive, sophisticated, Java 2 
Enterprise Edition (J2EE) and Web services technology-based application platform 
specifically designed to leverage the qualities of service inherent in the z/OS operating 
system. 


The WebSphere Application Server on the mainframe is the JZ2EE (Java! 2 Enterprise 
Edition) implementation conforming to the current Software Development Kit (SDK) 
specification supporting applications at an API Level. It is a Java Application 
deployment and runtime environment built on Open Standards based technology 
supporting all major functions such as Servlets, Java Server Pages (JSPs), and Enterprise 
Java Beans (EJBs) including the latest technology integration of services and interfaces. 


The application server runtime is highly integrated with all inherent features and services 
offered on z/OS. The application server inter operates with all major subsystems on the 
operating system including DB2, CICS, and IMS. It has extensive attributes for security, 
performance, scalability and recovery. The application server also uses sophisticated 
administration and tooling functions providing seamless integration into any data center 
or server environment. 


Through the incorporation of open standards such as HTML, HTTP, HOP, RMI/IIOP, 
SOAP and XML current and new e-business applications or transactions can be scaled up 
for global usage regardless of the Java development environment. Furthermore, new 
applications can be integrated with the extensive inventory of existing mainframe 
business functions resulting in the rapid creation of production-ready e-business 
applications. 


The Controller Address Space will automatically start a servant region as work arrives. A 
Application Server instance is composed of a Controller Region (CR) and one or more 
Servant Regions (SR). 


Application 


Instance 


The Application Server on z/OS provides for two configurations and uses essentially the 
same architectural hierarchy regardless of the implementation. The application server is 
organized based on the concepts of cells, nodes and servers. While all these elements are 
present in each configuration, cells and nodes do not play an important role until you 
implement the Network Deployment configuration. 


Chapter 15. HTTP Server and WebSphere Application Serveron z/OS 15-11 


Chapter15 websphere.fm Draft Document for Review December 3, 2004 3:15 pm 


15-12 


> Servers - These perform the code execution for you application. There are several 
types of servers, depending on the configuration. Each server runs in its own Java 
Virtual Machine (JVM). 


Application Server is the primary runtime component in all configurations. This is 
where the application actually executes. They provide containers and services that 
specialize in enabling the execution of specific Java application components. Each 
application server runs in its own JVM. All WebSphere Application Server 
configurations can have one or more application servers. Within this runtime you 
have a Base Configuration which each application server functions as a separate 
entity. There is no workload distribution or common administration among the 
application servers. The other runtime is called the Network Deployment 
configuration, multiple application servers are maintained from a central 
administration point. In addition, application servers can be clustered for workload 
distribution. Another type of Application Server is a JMS Server which is not covered 
in this course. 


> Nodes (and Node Agents) - A node is a logical grouping of WebSphere-managed 
server processes that share common configuration and operational control. A node is 
generally associated with one physical installation of the Application Server. 


As you move up to the more advanced Application Server configurations, the 
concepts of configuring multiple nodes from one common administration server and 
workload distribution among nodes are introduced. In these centralized management 
configurations, each node has a node agent that works with a Deployment Manager to 
manage administration processes. 


> Cells - A cell is a grouping of nodes into a single administrative domain. In the Base 
configuration, a cell contains one node. That node may have multiple servers, but the 
configuration files for each server are stored and maintained individually 
(XML-based). 


With the Network Deployment configuration, a cell can consist of multiple nodes, all 
administered from a single point. The configuration and application files for all nodes 
in the cell are centralized into a cell master configuration repository. This centralized 
repository is managed by the Deployment manager process and synchronized out to 
local copies held on each of the nodes. 


Within the address spaces used for the application server there is a concept of containers 
that provide runtime separation between the various artifacts that execute. There is a 
single container used to run Enterprise Java Beans known as an EJB container and the 
other is used to execute Web related elements such as HTML, GIFs, Servlets and Java 
Server Pages (JSPs) known as the Web container. Together they make up the application 
server’s runtime within the Java Virtual Machine (JVM). 
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15.3.1 J2EE Application Model on z/OS 


The J2EE Application Model on z/OS is exactly the same as on other platforms and 
follows the SDK specification exhibiting the following qualities. 


Functional - satisfies user requirements 

Reliable - performs under changing conditions 

Usable - enables easy access to application functions 
Efficient - uses system resources wisely 

Maintainable - can be modified easily 

Portable - can be moved from one environment to another 


vvvvvy 


The WebSphere Application Server on z/OS supports four major models of application 
design: Web-based computing, integrated enterprise computing, multithreading 
distributed business computing and service oriented computing. All these design models 
focus on separating the application logic from the underlying infrastructure, that is, the 
physical topology and explicit access to the information system is distinct from the 
programming model for the application. 


The J2EE programming model supported by WebSphere Application Server for z/OS 
makes it much easier to build applications for new business requirements because it 
separates the details from the underlying infrastructure. It provides for the deployment of 
component and service -oriented programming model offered by J2EE. 


15.3.2 Running WebSphere Application Server on z/OS 
Basics of WebSphere on z/OS 


The Application Server runs as a standard subsystem on the z/OS, therefore inherits all 
characteristics of mainframe attribute qualities and functionality which accompanies this 
platform. The mainframe is a multi-tasking, multi-processing platform that runs hundreds 
of heterogeneous workloads concurrently providing resources where and when they are 
needed executing at 100% capacity 24 x 7 meeting service level objectives as defined by 
the user. 


Consolidation of workloads 

The mainframe can be used to consolidate workloads from many individual servers, 
therefore if there is a large administration overhead or a physical capacity concern of 
many individual servers, the mainframe can take on the role of a single server 
environment managing those workloads. It can present a single view of administration, 
performance and recovery for those applications which will harness the mainframe’s 
services during execution. Several application servers can easily be migrated into one or 
several LPARs providing ease of management and monitoring. The consolidation also 
allows for instrumentation and metric gathering providing for ease of overall capacity 
and vital analysis needs. 
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WebSphere for z/OS Security 


The mainframe is a highly secured platform and has prominence in the industry having 
never been hacked, exposed to any viruses nor incurred intrusion. It has the highest rating 
Security rating offered by the U.S. Federal Government and is known throughout its 
history praised by many analysts and research organization as the most optimal server 
that will protect data. The combination of hardware and z/OS software inherent security 
along with incorporating the J2EE Security offers the ultimate defense against any 
possible violation. The product security is a layered architecture built on top of the 
operating system platform, the Java Virtual Machine (JVM) and Java2 Security. 
WebSphere Application Server for z/OS integrates infrastructure and mechanisms to 
protect sensitive J2EE resources and administrative resources addressing the enterprise 
from an end-to-end security perspective based on industry standards. The open 
architecture possess secure connectivity and inter operability with all mainframe 
Enterprise Information Systems which includes: 


CICS Transaction Server (TS) 
DB2 

Lotus Domino 

IBM Directory 


vvvy 


WebSphere application server integrates with RACF and WebSEAL Secure Proxy 
(Trusted Association Interceptor) providing a unified, policy-based and permission based 
model for securing all web resources and Enterprise JavaBean components as defined in 
the J2EE specification. 


Continuous availability 

WebSphere for z/OS uses continuous availability using the infrastructure’s transparent 
error detection and correction internal capabilities implementing hardware component 
redundancy. It has recovery termination management that detects, isolates, corrects and 
recovers from software errors, ability to differentiate and prioritize work based on service 
level agreements, clustering capability, ability to make non-disruptive changes to 
software components, such as z/OS, WebSphere Application Server Instances and its 
resource managers. 


When you have a critical application, WebSphere on z/OS can implement a facility to 
manage failures. z/OS provides a robust automation feature referred to as the Automatic 
Restart Manager to detect and recover from failures providing for restarting of servers 
when failures occur. WebSphere uses the z/OS Automatic Restart Manager (ARM) to 
recover Application Servers (Servants). Each Application Server running on a z/OS 
system are registered with an ARM Restart Group. This is performed via the ARM 
Coupled Datasets and ARM Policy working in conjunction with RRS. 


The Sysplex Distributor (SD) incorporates WLM and PR/SM provides for higher 
availability than the previously discussed option. WebSphere Application Server for 
z/OS takes full advantage of features provided by z/OS Parallel Sysplex. The Sysplex 
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Distributor uses Dynamic Virtual IP Addressing ensuring that the availability and 
throughput of an application server instance is continuous. This is the recommended 
solution for continuous availability when you have Application Server Clones residing in 
multiple LPARS. This is the form of LPAR Clustering as you can see in Figure 15-5 on 
page 15-15, not WebSphere Clustering which will be discussed in a later section. 
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Figure 15-5 WebSphere with Sysplex Distributor 








WebSphere Application Server for z/OS can implement a feature called clustering. 
Clustering technology is used extensively in the high availability solutions involving 
WebSphere see Figure 15-6 on page 15-16. A cluster consists of multiple copies of the 
same component with the expectation that at least one of the copies will be available to 
service a request. In general the cluster works as a unit where there is some collaboration 
among the individual copies to ensure that the request can be directed toward a copy that 
is capable of servicing the request. The designers of a high available solution participates 
in establishing a service level as they determine the number and placement of individual 
members of clusters. The WebSphere product provides the management for some of the 
clusters needed to create the desired service level. Greater service levels of availability 
can be obtained as WebSphere clusters are supplemented with additional cluster 
technologies. 
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Figure 15-6 Clustering of Server in Cell 


A WebSphere Application Server Cluster is composed of individual cluster members 
having each member contain the same set of applications. In front of a WebSphere 
Application Server cluster is a workload distributor which routes the work to individual 
members. A cluster can be vertical within an LPAR, that is two or more members 
residing in a z/OS system image or they can be placed horizontally across LPARs where 
you obtain the highest in availability in the event an LPAR containing a member has an 
outage. Workload in this case can still be taken on from the remaining cluster members. 
Also within these two configurations we can have a hybrid where the cluster members 
are composed of vertical and horizontal (see Figure 15-7 on page 15-17). 
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Figure 15-7 Vertical and Horizontal Cluster 


Performance 


Performance is highly dependent on application design and coding regardless of the 
power of the runtime platform. A defectively written application will perform just as 
poorly on z/OS than as intended for another machine’s architecture. WebSphere 
Application Server for z/OS harness the mainframe qualities in hardware and software 
characteristics incorporating Workload Management schemes, dynamic LPAR 
configuration, and Parallel Sysplex functionality. 


The WebSphere Application Server for z/OS utilizes the three distinct functions of the 
mainframes workload manager: 


> Routing - WLM routing services are used to direct clients to servers on a specific 
server based on measuring of current system utilization known as the Performance 
Index (PI). 


> Queuing - The WLM queuing service is used to dispatch work requests from a 
Controller Region to one or more Server Regions. It is possible for a Work Manager 
to register with WLM as a Queuing Manager. This tells WLM that this server would 
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like to use WLM managed queues to direct work to other servers. This allows WLM 
to manage server spaces to achieve the specified performance goals established for 
the work. 


> Prioritize - The application server provides for starting and stopping Server Regions 


to set work precedence. This allows WLM to manage application server instances in 
order to achieve goals specified by the business. 


Important: WLM maintains a performance index (PI) for each service class period in 
order to measure how the actual performance varies from the goal. Since there are 
several types of goals, WLM needs some way to compare how well or how poorly 
work in one service class is doing compared to other work. 


A Service Class (SC) is used to describe a group of work within a workload with 
equivalent performance characteristics. 


15.3.3 Application Server Configuration on z/OS 
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Base Server Node 

The base application server node is the simplest operating structure in the Application 
Server for z/OS. It consist of an Application Server and a Daemon Server (one Node and 
one Cell), as shown in Figure 15-8 on page 15-19. All of the configuration files and 
definitions are kept in the HFS directory structure created for this base application server. 
The Daemon Server is a special server with one controller region. The system 
architecture of WebSphere for z/OS calls for one Daemon server per cell per system or 
LPAR. 


Each Base Application Server Node contains administration for its own cell domain and 
a separate repository for its configuration. Therefore, you can have many Base 
Application Servers each isolated from one another having its own administration policy 
for its specific business needs. 
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Figure 15-8 Base Server Node 


Network Deployment Manager 

Network Deployment Manager (see Figure 15-9 on page 15-20) is an extension to the 
Base Application Server having a deployment manager packaged within this 
configuration. Unlike the Base Application Server the Deployment Manager allows the 
system to administer multiple application servers from one centralized location. With the 
Deployment Manager, horizontal and vertically scaled systems as well as distributed 
applications can be easily administered. 


In this topology, application servers are attached to nodes and multiple nodes belong to a 
cell. 


The network deployment manager also takes care of the repositories on each node, as 


such tasks as create/maintain/remove. They system uses an extract/modify method to 
update the configuration. 
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Figure 15-9 Network Deployment Manager 





15.3.4 Connectors for the Enterprise Information Systems (EIS) 
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The ability of applications to interface with resources outside of the application server 
process and to use those resources efficiently has always been an important requirement. 
Equally important is the ability for vendors to plug-in their own solutions for connecting 
to and using their resources. 


An application might require access to many types of resources which may or may not be 
located in the same machine as the application. Therefore, access to a resource begins 
with a connection which is a pathway from an application to a resource requiring use. 
That resource might be another transaction manager or database manager. 


Java Program access to a broad range of back-end resources is performed through a 
resource adapter. This is a system level software driver that plugs into an application 
server and enables a Java application to connect to various back-end resources. The 
specification provides the necessary interfaces for supporting these resource types as well 
as the interface for use by application programmers. 


The following considerations are common to all connections: 


> Creating a connection can be expensive - setting up a connection can take a long time 
when compared to the amount of time the connection is actually used. 
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> Connections need to be secured - this is often a joint effort between the application 
and the server working with the resource. 


> Connection need to perform well - the connection performance can be critical to the 
success of an application and is a function of the application overall performance. 


> Connections need to be monitorable and good diagnostics - the quality of the 
diagnostics for a connection depends on the information regarding the server and 
resource status. 


> Methods for connecting to and working with a resource - different database 
architectures require different means for access from an application server. 


> Quality of Services comes into play accessing resources outside of the application 
server - the application may require the acid (atomicity, consistency, isolation and 
durability) properties that can be obtained when using data in managing a transaction 


Enterprise resources are often legacy resources that were developed over time by a 
business and are external to the application server process. Each type of resource has its 
own connection protocol and proprietary set of interfaces to the resource meaning that 
the resource has to be adapted to be accessible from a JVM process as contained in an 
application server. The Application Server has facilities to interface with other 
mainframe subsystems such as CICS, DB2 and IMS. This is performed through a 
resource adapter and a connector. Accessing back-end Enterprise Information Systems 
(EIS) extends the functionality of the application server into existing business functions 
providing enhanced capabilities reaching all corporate needs of deployment. 


The Java Cryptography Architecture (JCA) defines the contracts between the application, 
the connector and the application server where the application is deployed. The 
application has a component called the resource adapter. This is contained within the 
application code handling the interface to the connector which the application developer 
creates. From a programming perspective, this means that the programmer only has to 
use a single unified interface with which they can obtain data from the EIS. The resource 
adapter will take care of abstracting out the different elements and provide the 
programming model that is independent of the actual EIS behavior and communication 
requirements. 
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Figure 15-10 The basic architecture of a connector to an EIS. 


15.3.5 Three major mainframe connectors 
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CICS Transaction Gateway 

Customer Information Control System has the CICS Transaction Gateway (CTG) used to 
connect from the Application Server to CICS. It provides the interface between Java and 
CICS application transactions. It is a set of client and server software components 
incorporating the services and facilities to access CICS from the application server. 


The CTG uses special APIs and protocols within servlets or EJBs in order to request 
services and functions of the CICS Transaction manager. 


IMS Connect 


IMS Connect is the connector TCP/IP server that enables an Application Server client to 
exchange messages with IMS OTMA (Open Transaction Manager Access). This server 
provides communication links between TCP/IP clients and IMS (datastores). It supports 
multiple TCP/IP clients accessing multiple datastore resources. To protect information 
that is transferred through TCP/IP, IMS Connect provides Secure Sockets Layer (SSL) 
support to protect and secure the information. 
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IMS Connect can also performs router functions between Application Server clients and 
local option clients with datastores and IMSplex resources. Request messages received 
from TCP/IP clients, using TCP/IP connections, or local option clients, using the z/OS 
Program Call (PC), are passed to a datastore through cross-system coupling facility 
(XCF) sessions. IMS Connect receives response messages from the datastore and then 
passes them back to the originating TCP/IP or local option clients. IMS Connect supports 
TCP/IP clients communicating with socket calls, but it can also support any TCP/IP 
client that communicates with a different input data stream format. User-written message 
exits can execute in the IMS Connect address space to convert customer message format 
to OTMA message format before IMS Connect sends the message to IMS. The 
user-written message exits also convert OTMA message format to customer message 
format before sending a message back to IMS Connect. IMS Connect then sends output 
to the client. 


DB2 JDBC 


The Java Database Connectivity (JDBC) is an application programming interface (API) 
that the Java programming language uses to access different forms of tabular data, as 
well as some hierarchical systems such as IMS. The JDBC specifications were developed 
by SUN Microsystems to gather with relational database providers, such as Oracle and 
IBM to ensure portability of Java applications across database platforms. 


This interface does not necessarily fall into the line of connectors since there is no 
separate address space required for its implementation. The interface is a Java construct 
that looks like a Java class but does not provide an implementation of its methods. In the 
case of JDBC, the actual implementation of the JDBC interface is provided by the 
database vendor as a “driver”. This provides portability in that all access using the JDBC 
is through standard calls with standard parameters. Thus an application can be coded 
with little regard to the database you are actually using as all the platform-dependent 
code is stored in the JDBC drivers. 


JDBC also has to be flexible in what functionality it does and does not provide solely 
based on the fact that different database systems have different levels of functionality. 


The JDBC drivers provide the physical code that implements the objects, methods and 
data types defined in the specification. The JDBC standards define four types of drivers 
numbered | through 4. The distinction between them is based on how the driver is 
physically implemented and how it communicates with the database. 

The mainframe supports only type 2 and type four drivers: 

> Type 2 


Here, the JDBC API calls platform- and database-specific code to access the 
database. This is the most common driver type used, and offers the best performance. 
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However, as the driver code is platform specific, a different version has to be coded 
(by the database vendor) for each platform. 


> Type 4 


A Type 4 driver is fully written in Java, and accesses the target database directly using 
the protocol of the database itself. In the case of DB2, this is DRDA. As the driver is 
fully written in Java, it can be ported to any platform that supports that DBMS 
protocol without change, thus allowing applications to also use it across platforms 
without change. 


Your Java applications running inside the a WebSphere Application Server talk to the 
(Universal) Type 4 JDBC driver that supports two-phase commit, and the driver talks 
directly to the remote database server through DRDA. The Universal Type 4 driver 
implements DRDA Application Requester functionality. 


In order to access DB2 UDB for OS/390 or z/OS, IBM provides a type 2 driver and a 
driver that combines type 2 and type 4 JDBC implementations. 


In general, you should use JDBC type 2 connectivity for Java programs that run on the 
same z/OS system with the target DB2 subsystem. Use JDBC type 4 connectivity for 
Java programs that run on a different z/OS system from the target DB2 subsystem. 


15.4 Summary 
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In the WebSphere chapter we have seen that z/OS is the perfect HTTP Server as well for 
Statics as for Dynamic webpages. There is the WebSphere plugin, with or without EJB 
container, using J2EE or not. HTTP server basic functions, security and File caching are 
included in the z/OS HTTP Server. All of them making it easier to work with dynamic 
webpages 


The WebSphere Application server for z/OS is comprehensive, sophisticated, J2EE and 
Web Service technology-based application, based on the service quality of z/OS. The 
open standards like HTML, HTTP, IIOP,... are incorporated, so new applications and 
transactions can be scaled up. The new application can even be integrated in the existing 
mainframe functions. 


The application server is organized based on the concept of cells, nodes and servers. 
Within the address spaces, the concept of containers provides runtime separation between 
various artifacts that execute. 


The J2EE application Model follows the SDK specifications like on all other platforms 
and it makes it easier to build applications, because it separates the details from the 
underlying infrastructure. 
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We have also seen how to configure the application server on z/OS as well as the major 
connectors to CICS, IMS and DB2 JDBC. 
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15.5 Discussion questions 


1. What is the main difference between the HTTP Server and the WebSphere 
Application Server? 


2. Discuss the advantages of having an Application Server running on z/OS rather than 
running other platforms. 


3. Can you figure out, for which reasons the Connectors should be used. 


4. Why are not all documents generally stored in ASCII format, so that the documents 
don’t have to become converted? 


15.6 Demonstrations and Exercises 
Work with the ISHELL or OMVS shell for this exercise 


The instructor should tell you 


— where to find the HTTP Server configuration file, call httpd.conf 
— IP address or name of the z/OS HTTP server you could use 


1. Take a look (browse) into the httpd.conf file of the HTTP server installed on your 
host. 


a. In which directory the Web documents are stored? (F “URL translation rules’’) 
b. Which port should be used (F “Port directive”) 

2. Start your Web browser and point to the class HTTP Server. 

3. How is WebSphere plugged into this HTTP server? (F ““Websphere’’) 
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4. Using the OEDIT create a HTML document in the Web documents folder. Name it 
youridtest.html 


<!doctype html public "//W3//Comment//EN"> 
<html> 

<head> 

<META content="text/html; charset=iso-8859-1"> 
<title> This is a simple HTML Exercise</title> 
</head> 

<body bgcolor="#FFFFFF"> 

<p>Hello World 

</body> 

</htm|> 


5. Point the WebBrowser to this html file: 
www. yourserver.com/youridtest.html 
6. What has to be done to install your own CGI? 


7. Look in the httpd.conf file - is the HTCounter CGI, Option “Date and Time” 
enabled? If yes, change youridtext.htm]l and add in the body section the 
following line 


<img src="/cgi-bin/datetime?Timebase=Local "> 


8. Check your results 
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15.7 Instructor Notes 


Refer to “Continuous availability” on page 15-14 


Web Server - software program that responds to information requests generated by web 
browsers. 
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A cluster is a grouping of two or more servers within a cell into a logical entity 


Clusters can't span cells. They must consist of servers within the same Deployment Manager cell. They may span systems 
in a Sysplex, but only if the cell also spans those systems. 


Applications are then installed into the cluster; WebSphere will automatically deploy the app into all the 
servers in the cluster 


Refer to “Performance” on page 15-17 

The WebSphere Application Server for z/OS uses a unique z/OS facility called the 
Application Environment (AE). This environment can be thought of as a set of server 
address spaces belonging to the same subsystem instance, started by the same procedure 
and having the same capabilities (in terms of programs, libraries, accessible data and 
security authorization). Different transactions in an AE may have different performance 
goals (characteristics) consequently different service characteristics. Each unique 
combination of AE and service class defines an application environment queue. WLM 
creates queues for transactions coming from the subsystem work manager. WLM 
samples the queues in order to decide if a new address space for this environment needs 
to be created. This feature allows for the automatic creation of additional Servant 
Address Spaces as the workload increase and will destroy the additional Servants as the 
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workload decreases providing dynamic use of CPU, Storage and I/O resources upon 
demand. There is no requirement to predefine additional Servants (CPU and storage), 
anticipating workload. The subsystem work manager in “WebSphere for z/OS” case the 
Controller Region (CR) fetches work from these queues and will create at least on 
Servant Region (SR) address space per Application Environment/service class 
combination. The AE on z/OS is used to control automatically the number of server 
address spaces a subsystem will use to manage throughput. The procedure name assigned 
to a Controller Region depending on WLM service definition will dictate the speed 
(velocity) of how quickly the Servant Region will be brought up. 


You can also use the Performance Monitoring Infrastructure (PMI) interfaces to develop 
your own applications to collect and display performance information. There are three 
such interfaces - a Java Machine Extension (JMX)-based interface, a PMI client 
interface, and a servlet interface. All three interfaces return the same underlying data. 
The JMX interface is accessible through the AdminClient tool. The PMI client interface 
is a Java interface. The servlet interface is perhaps the simplest, requiring minimal 
programming, as the output is XML. 


Refer to “DB2 JDBC” on page 15-23 
DB2 JDBC supported drivers 


Following, a short description of both of them: 


> DB2 Universal JDBC Driver for z/OS 
The DB2 Universal JDBC Driver is a single driver that includes JDBC type 2 and 
JDBC type 4 behavior, as well as SQLJ support. When an application loads the DB2 
Universal JDBC Driver, a single driver instance is loaded for type 2 and type 4 
implementations. The application can make type 2 and type 4 connections using this 
single driver instance. The type 2 and type 4 connections can be made concurrently. 
DB2 Universal JDBC Driver type 2 driver behavior is referred to as DB2 Universal 
JDBC Driver type 2 connectivity. DB2 Universal JDBC Driver type 4 driver behavior 
is referred to as DB2 Universal JDBC Driver type 4 connectivity. 


> Legacy JDBC type-2 driver for DB2 for z/OS 
The JDBC/SQLJ 2.0 Driver for OS/390 is a type 2 driver that contains most of the 
functions that are described in the JDBC 1.2 specification. This driver also includes 
some of the functions that are described in the JDBC 2.0 specification. This is the 
Legacy DB2 for z/OS Local JDBC type-2 compliant driver that has been available 
since the first release of WebSphere Application Server 5.0 for z/OS. This driver 
supports 2-phase commit processing 


If you need two phase commit processing (2PC) on JDBC Type 4 connections, you need 
a particular JDBC T4 driver, called Type 4-XA. IBM makes available this kind of driver 
with a different JDBC provider from Type 4. 
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application connector DB2 


15.8 More information about WebSphere Host 
Integration Solution 


The WebSphere Host Integration Solution provides a set of products to address the 
legacy application extension space. It also comprises industry-leading software 
communication clients and servers providing a variety of products to meet your network 
needs, it includes: 


15.8.1 WebSphere Host Access Transformation Server 


An easy-to-implement Web-to-host solution that delivers HTML to your users’ Web 
browsers, allowing you to extend legacy applications to end users. Its rules-based 
transformation engine dynamically converts host screens to Web-like graphical user 
interfaces (GUIs) to provide a quick and efficient way to integrate legacy assets into 
e-business applications. 


15.8.2 WebSphere Host On-Demand 


A browser-based, thin-client terminal emulator that supports 3270, 5250 and virtual 
terminal (VT) emulation and provides an extensive set of programming tools to quickly 
create and customize e-business applications. It is essentially a full set of terminal 
emulation facilities that have been written entirely in Java. It allows a Web browser to 
download terminal emulation applets ”on-demand” in order to interface with a variety of 
applications including, 3270 based applications such as those running in CICS or IMS. 
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WebSphere Host On-Demand can offer CICS 3270 terminal users, a quick and easy way 
to access an existing application from a Web browser with no changes to their existing 
application environment. Since WebSphere Host On-Demand provides a full function 
3270 emulator within a browser, there are no restrictions on what type of 3270 or 
transaction can be supported. 


15.8.3 WebSphere Application Server 


A powerful deployment environment for Java applications and components, including 
support for EJB technology with clustering, caching, security and transaction support for 
e-business applications. WebSphere Application Server, Advanced Edition combines the 
control and portability of server-side business applications and XML with the 
performance and manageability of Java technologies and application programming 
interfaces (API). IBM WebSphere Application Server, Advanced Edition also extends the 
value and versatility of your Web server with such functions as a simple graphical user 
interface and extensive monitoring and reporting tools. 


15.8.4 WebSphere StudioSite Developer 


A tool suite that brings together all aspects of Web application development into a 
common interface, providing everything developers need to create, manage and maintain 
compelling dynamic Web sites. WebSphere Studio Site Developer makes it easy for all 
team members to create, assemble, publish, deploy and maintain dynamic, interactive 
Web applications designed to meet the requirements of today's open technology 
standards. 


15.8.5 Personal Communications 


A comprehensive communications client that offers 3270, 5250 and VT emulation as 
well as a variety of APIs. 


15.8.6 Communications Server 
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A powerful, multifunction, multipurpose gateway that connects diverse applications and 
network environments. Communications Server enables workstations to communicate 
with other workstations and host computers, regardless of platforms and network 
configurations giving you the freedom to choose applications based on business needs 
rather than your network protocol. 


Individually, these products are powerful tools, but together they provide a 
comprehensive solution for deploying host-access and e-business applications across 
intranets, extranets and the Internet. All at a modest cost. You can choose the 
combination of client, server and platform software you need —in a single offering to 
precisely meet the needs of your business. 
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WebSphere Host Integration Solution can meet your Web-to-host business needs today 
and in the future. WebSphere Host Integration Solution: 


> 


Vv 


Provides a fast, easy and cost-effective way to take host applications and data to the 
Web 

Requires no changes to host applications 

Requires no scripting or coding 

Addresses all aspects of a business network environment: SNA, TCP/IP, intranet, 
extranet and the Internet 

Delivers technology uniquely designed to support specific types of users 

Can enable platform and technology migrations without additional purchases 
Supports a common development infrastructure and the ability to create and deploy 
host access business applications in a WebSphere software platform environment 
Provides security for your business transactions. WebSphere Host Integration 
Solution offers industry-leading host access solutions with unmatched flexibility for 
multiple environments, meeting virtually all of your host access business needs. 
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Messaging and queuing on z/OS 








Objective: This chapter will learn you about messaging and queuing. This is 
not only used on mainframes, but (almost) every platform can use it. So it does 
make the communication between them much easier. 


In this chapter, you will learn: 


the need for messaging and queueing 
how asynchronous thinking works 

what the Queue Manager is 

the types of queues 

why you need channels 

how to interface with CICS, IMS or batch 





vvvvvy 

















16.1 Islands of automation 


Even within their own enterprises, most large organizations today have an inheritance of 
IT systems from various manufacturers. Many would also like to communicate 
electronically with their suppliers and their customers who may have yet other disparate 
systems. 


Even where such techniques exist, there have been severe limitations on the application 
design choices available. Worse, where data held on different databases on different 
systems must be kept synchronized, very little is available in the way of protocols to 
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coordinate updates, deletions, and so forth. So it means that the mixed environments are 
hard to keep aligned, complex programming is required to integrate them. 


WebSphere Messaging and Queuing (MQ) is a means of program-to-program 
communication. Figure 16-1 on page 16-2 depicts the basic mechanism by which this 
communication takes place. 


Messaging means that programs communicate with each other by sending data in 
messages and not by calling each other directly. 


Queuing means that programs communicate through queues. Programs communicating 
through queues need not be executed concurrently. 


Program A prepares a message and puts it on a queue 1. Program B then gets the message 
from the queue | and processes it. Both Program A and Program B use an application 
programming interface (API) to put messages on a queue and get messages from a queue. 
The WebSphere MQ API is called the Message Queue Interface (MQI). 

















Figure 16-1 Synchronous application design model 


Note that, when Program A puts a message on the queue 1, Program B may not be 
executing. The queue stores the message safely until Program B starts and is ready to get 
the message. Likewise, at the time when Program B gets the message from the queue 1, 
Program A may no longer be executing. Using WebSphere MQ, there is no requirement 
for two programs communicating with each other to be executing at the same time. 
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The Figure 16-1 shows also how Program B can send a message back to Program A 
using the same mechanism. The message may be a reply to a message it has already 
received from Program A. It is normal that the queue 2 used by Program B to send a 
message to Program A is different from the one that Program A uses to send a message to 
Program B. However, this is not strictly necessary, but using separate queues does lead to 
a simpler application design and simpler programming logic. 


If Program A sends a message to Program B expecting a reply, one option is for Program 
A to put a message on Queue | and then wait for the reply to appear on Queue 2. This is 
called the synchronous model for two-way communication between programs. Using the 
synchronous model, Program A and Program B would normally be executing at the same 
time. However, if Program B fails, Program A might potentially have to wait a long time 
for a reply. There is clearly a design issue, therefore, of how long Program A should wait 
before continuing with other processing. This may be good in some situations, but when 
the wait is too long, it is not so good anymore. 


16.2 Asynchronous thinking 


Message-driven communication allows applications to transmit data asynchronously. In 
contrast to synchronous communication, the two parties need not to be up and running 
during the communication. 


It is possible to compare this principle with E-mail: The sender sends a message and 
continues its work without waiting for an instant reply. The recipient doesn’t have to be 
online when the message is sent. Later he may or may not reply to the message, or he 
even could send a message not related to the previous one received. 


Over the past several years, many software companies developed message-oriented 
middleware (MOM). WebSphere MQ, formerly known as MQSeries, is one of them. It 
uses messages and queues to achieve asynchronous communication. 


Using the asynchronous model, Program A puts messages on Queue | for Program B to 
process, but it is Program C, acting asynchronously to Program A, which gets the replies 
from Queue 2 and processes them. Typically, Program A and Program C would be part of 
the same application. You can see this in Figure 16-2. 
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Figure 16-2 Asynchronous application design model 


The asynchronous model is the natural model for WebSphere MQ. Program A can 
continue to put messages on Queue | and is not blocked by having to wait for a reply to 
each message. It can continue to put messages on Queue | even if Program B fails. In 
that case, Queue | stores the messages safely until Program B is restarted. In a variation 
of the asynchronous model, Program A could put a sequence of messages on Queue 1, 
optionally continue with some other processing, and then return to get and process the 
replies itself. 


Another advantage of thinking this way is that Program A can put messages on the queue 
and Program B will get them when it is ready. So, if Program B is busy or is not 
available, the messages are stored safely in the queue until it is ready to get them. If, at 
the point when B becomes ready, Program A has completed its processing or has failed, it 
does not matter. Program B can still get the messages and process them. Indeed, there 
may be times when neither program is available, but any outstanding messages are still 
stored safely in the queue. This property of WebSphere MQ, in which communicating 
applications do not have to be active at the same time, is known as time independence. 
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16.3 Styles of communication 


Conversational or transaction-oriented communication is characterized by two or more 
programs executing simultaneously in a cooperative manner in order to perform a 
transaction. They communicate with each other through an architected interface. While 
one program is waiting for a reply from another program with which it is cooperating, it 
may continue with other processing. 


The call and return style is similar except that the interface is structured to resemble a call 
and return mechanism. When one program calls another program, the former is blocked 
and cannot perform any other processing. Remote procedure call (RPC) is an example of 
this style of communication. 


The messaging style implies that communicating programs can execute independently of 
each other. An executing program receives input in the form of messages and outputs its 
results also as messages. A message that is the output from one program becomes the 
input to another program, but there is no requirement that the latter must be executing 
when the former outputs the message. Contrast this with the conversational and call and 
return styles where all cooperating partners must be executing at the same time. The 
messaging style is the one used by WebSphere MQ. 


These styles are shown in Figure 16-3 on page 16-5. 
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Figure 16-3 Types of communication 
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16.4 Messages 


You want to transfer data from an application to another. Messages are used by 
WebSphere MQ to transfer application-specific data. A message consists of two parts: 


> Data that is sent from one program to another 
> The message descriptor or message header 


The message descriptor identifies the message (message ID) and contains control 
information, also called attributes, such as message type, expiry time, priority, and the 
name of the queue for the reply. A message can be up to 4MB or 100MB long, depending 
on the version. 


16.4.1 Message types 


WebSphere MQ knows four types of messages: 

Datagram: A message containing information for which no response is expected. 
Request: A message for which a reply is requested. 

Reply: A reply to a request message. 

Report: A message that describes an event such as the occurrence of an error or a 


confirmation on arrival or delivery. 


The component of WebSphere MQ software which owns and manages queues is called a 
queue manager (QM). 


16.4.2 Queue manager 
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The heart of the WebSphere MQ is the message queue manager (MQM). It provides 
messaging services for an application, ensures that messages are put in the correct queue, 
routes messages to other queue managers and processes messages through a common 
programming interface called the Message Queue Interface (MQI). The Queue manager 
can retain messages for future processing in the event of application or system outages. 
Messages are retained in the queue until a successful completion response is received 
through the MQI. 


There are some similarities between database managers and queue managers. Queue 
managers own and control queues in a way similar to the way database managers own 
and control their data storage objects. They provide a programming interface to access 
data, and security, authorization, recovery and administrative facilities. 


But than of course, there are also some differences between database managers and 
queue managers. Databases are designed to provide long time data storage with 
sophisticated search mechanisms, queues are not. A message on a queue generally 
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indicates that a business process is incomplete; it might represent an unsatisfied request, 
an unprocessed reply or an unread report. 











QUEUE MANAGER’ 














Figure 16-4 Queue managers and database managers 


The queue manager transfers messages to other queue managers via channels using 
existing network facilities, such as TCP/IP or SNA. Multiple queue managers can reside 
in the same machine, but they also need channels to communicate with each other. More 
on this, later in this chapter. 


A queue manager also provides the Message Queue Interface (MQI) to enable an 
application to access its queues and the messages they contain. The MQI is a simple 
application programming interface which is consistent across all platforms supported by 
WebSphere MQ. The MQI effectively protects applications from having to know how a 
queue manager physically manages messages and queues as shown in Figure 16-5 on 
page 16-8. 


The program languages supported by WebSphere MQ are Assembler, C, C++, COBOL, 
JAVA, PL/I, RPG, TAL, and Visual Basic. 


An application must first connect to a queue manager before it can access any of its 


resources. To do this, it issues an MQCONN or MQCONNX call. When the application 
no longer needs to be connected to the queue manager, it issues an MQDISC call. 
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Figure 16-5 MQI Calls 


To access a queue, an application must first issue an MQOPEN call. When it no longer 
requires access to the queue, the application issues an MQCLOSE call. 


Once a queue is opened, an application uses an MQPUT call to put a message on the 
queue and an MQGET call to get a message from the queue. The MQPUTI call enables 
an application to open a queue, put one message on the queue, and close the queue, all in 
a single call. 


The MQBEGIN, MQCMIT, and MQBACK calls enable an application to put and get 
messages as part of a unit of work. 


A queue is an example of a WebSphere MQ object. However, there are other types of 
WebSphere MQ objects, such as a process, a namelist and the queue manager object. 


Every WebSphere MQ object has a set of attributes. Each attribute has a name and a 
value. The definition of a WebSphere MQ object specifies the values of its attributes. 


Every WebSphere MQ object has a name which is considered to be one of its attributes. 


An application can use an MQINQ call to inquire on the values of some or all of the 
attributes of an object. It can use an MQSET call to set the values of certain attributes of 
a queue only. 


MQ has two additional application programming interfaces, the Application Messaging 
Interface (AMI), which reduces the application programmer's need to code the MQI 
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calls, and Java Message Service (JMS) which allows programmers to write event-based 
messaging applications. The EJB 2.0 specification incorporates Message Driven 
Beans.These application programming interfaces is not discussed, more information can 
however be found in WebSphere MO Using Java. 


A message has two parts, the various headers used by WebSphere MQ and the 
application data. The application data is private to the applications. It is possible to have 
a message with no application data. 


All WebSphere MQ messages will always have a header called the message descriptor 
(MQMD), see Figure 16-6. The message descriptor contains certain control information 
about the message which is used by both the queue manager and the receiving 
application. It contains a number of fields which we will review as we continue on. There 
are other headers which may or may not be in use with a message. Among them are: 


> Transmission queue header (MQXQH): Contains delivery information in remote 
queuing. 

> Dead-letter header (MQDLH): Identifies conditions that prevented delivery to 
destination queue. 

> Reference message header (MQRMH): Contains information to assist in delivery of 
reference messages 

> IMSrtm. information header (MQUH): Carried with messages using the IMS bridge 
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Figure 16-6 Message 


There is no restriction on the contents of the application data but there is a maximum 
allowable length for a message which varies by platform. 
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16.5 Message queues 


Message queues are used to store messages sent by programs. They are defined as objects 
belonging to the queue manager. 


When an application puts a message on a queue, the queue manager ensures that the 
message is: 


> stored safely, 
> is recoverable, and 
> is delivered once and once only to the receiving application. 


This is true even if a message has to be delivered to a queue owned by another queue 
manager, and is known as the assured delivery property of WebSphere MQ. 


16.5.1 Queue Types 


16-10 


There are several types of queues. We want to mention the most important queue types in 
this section. 


Local queue 

A queue is local if it is owned by the queue manager to which the application program is 
connected. It is used to store messages for programs that use the same queue manager. 
The application program don’t have to run on the same machine as the queue manager. 


Remote queue 

A queue is remote if it is owned by a different queue manager. A remote queue is not a 
real queue. It is only the definition of a remote queue to the local queue manager. A 
program is not possible to read messages from a remote queue. Remote queues are 
associated with a transmission queue. 
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Figure 16-7 Local and remote queues 


Transmission queue (xmitq) 

This is a local queue with special purpose. A remote queue is associated with a 
transmission queue. Transmission queues are used as an intermediate step when sending 
messages to queues that are owned by a different queue manager. Transmission queues 
are transparent to the application. They are used internally by the queue manager. On 
Figure 16-7 QX is an example of a transmission queue. 


Initiation queue 

This is a local queue to which the queue manager writes, transparent to the programmer, 
a trigger message when certain conditions are met on another local queue, for example, 
when a message is put into an empty message queue or in a transmission queue. Two 
WebSphere MQ applications monitor initiation queues and read trigger messages, the 
trigger monitor and the channel initiator. The trigger manager can start applications 
depending to the message. The channel initiator starts the transmission between queue 
managers. 


Dead-letter queue 
A queue manager must be able to handle situations when it cannot deliver a message. 
Here are some examples: 


> The destination queue is full. 
> The destination queue does not exist. 
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Message puts have been inhibited on the destination queue. 
The sender is not authorized to use the destination queue. 
The message is too large. 

The message contains a duplicate message sequence number. 


vvvy 


When one of the above conditions is true, the message is written to the dead-letter queue. 
Such a queue is defined when the queue manager is created ana each QM should have 
one. It will be used as a repository for all messages that cannot be delivered. On 
Figure 16-7 on page 16-11 DLQ is an example of a dead-letter queue. 


So, how does this work for an application? When an application opens a queue, the queue 
manager determines whether the queue is a local queue, that is, one owned by the queue 
manager to which the application is connected, or whether it is a remote queue, that is, 
one owned by another queue manager. When the application subsequently issues an 
MQPUT call to put a message on a queue which is local, the queue manager places the 
message directly on that queue. But if the queue is remote, the queue manager places the 
message instead on a special queue called a transmission queue. 


It is then the task of a message channel agent (MCA), a supplied component of 
WebSphere MQ software, to get the message from the transmission queue and send it 
over the network to an MCA at the receiving end. The receiving MCA then puts the 
message on the destination queue. Once the message has been safely committed on the 
destination queue, it is removed from the transmission queue. 


If the receiving MCA cannot put the message on the destination queue for any reason, the 
message is: 


> put on the dead letter queue, or 
> returned to the sender, or 
> discarded 


depending on the options specified by the sending application in the message descriptor. 


And this brings us to channels. 


16.6 Channels 
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A channel is a logical communication link. In WebSphere MQ, there are two different 
kinds of channels: 


1. Message channels 


A message channel connects two queue managers via message channel agents 
(MCAs). Such a channel is unidirectional. It compromises two message channel 
agents, a sender and a receiver, and a communication protocol. An MCA transfers 
messages from a transmission queue to a communication link, and from a 
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communication link to a target queue. For bidirectional communication, it is 


necessary to define a pair of channels, consisting of a sender and a receiver. 


2. MQI channels 


An MQI channel connects a WebSphere MQ client to a queue manager. Clients don’t 
have a queue manager of their own. An MQI channel is bidirectional. 
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Figure 16-8 WebSphere MQ bidirectional communication 


16.7 Data integrity 


Some implementations of the conversational style of program-to-program 
communication support the implementation of a distributed unit of work using a 
two-phase commit protocol. However, this kind of function is only necessary when there 
is an absolute business requirement to maintain two or more distributed databases in step 
at all times, right down to the last fraction of a second. Such a requirement is encountered 
only rarely in practice. And if the requirement does not really exist, using a single 
distributed unit of work can be resource consuming and complex, particularly if many 
processes are involved. WebSphere MQ, on the other hand, offers a simple solution 
involving multiple units of work acting asynchronously. 
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Figure 16-9 Data integrity 


The WebSphere MQ solution is depicted in the lower half of Figure 16-9: 


> The first application writes to a database, puts a message on a queue, and then issues 
a syncpoint to commit the changes to the two resources. The message contains data 
which is to be used to update a second database on a separate system. As the queue is 
a remote queue, the message gets no further than the transmission queue within this 
unit of work. When the unit of work is committed, the message becomes available for 
retrieval by the sending MCA. 


> In the second unit of work, the sending MCA gets the message from the transmission 
queue and sends it to the receiving MCA on the system containing the second 
database. The receiving MCA then puts the message on the destination queue. All this 
is performed reliably because of the assured delivery property of WebSphere MQ. 
When this unit of work is committed, the message becomes available for retrieval by 
the second application. 


> Inthe third unit of work, the second application gets the message from the destination 
queue and updates the database using the data contained in the message. 


It is the transactional integrity of units of work 1 and 3, and the once and once only, 
assured delivery property of WebSphere MQ used in unit of work 2, which ensures the 
integrity of the complete business transaction. 


If the business transaction is a more complex one, many units of work may be involved. 
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16.8 Security 


Security is an important aspect of system management. We are only giving a brief 
explanation of some of the features provided. 


> A queue manager can check whether a user is authorized to enter commands which 
are used to manage the queue manager. 


> A queue manager can check whether a user or an application is authorized to access a 
WebSphere MQ resource, such as a queue, for a specified operation. 


> An MCA can authenticate a partner MCA before allowing messages to flow. 


> A message can be encrypted before it is sent by an MCA to its partner MCA. At the 
receiving end, the message can be decrypted. 


> A message descriptor may contain a user ID and other information about the 
originator of the message. This information is called the message context. 
Information in the message context can be used to authenticate a message, and to 
check whether the sender of the message has the authority to access a WebSphere MQ 
resource on the system on which the message is received. 





Local Queue Manager 












Application 
Data 


Database 











Figure 16-10 Security 
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The user ID might also be used to check whether the sender of the message has the 
authority to access a non-WebSphere MQ resource, such as a database, but whether this 
is possible depends on the security features provided by the respective resource manager. 


16.9 Online example 


To book a vacation with a travel agent requires a number of tasks. In the scenario 
depicted in the figure, an agent needs to reserve a flight and a hotel room, and rent a car. 
All of these tasks must be performed before the overall business transaction can be 
considered complete. 


Using WebSphere MQ, a request message can be put on each of three queues which are 
serving the car rental application, the flight reservations application, and the hotel 
reservations application. Each application can then perform its respective task in parallel 
with the other two and put a reply message on the reply-to queue. The agent's application 
can then get the three replies and produce a consolidated answer. 





MQPUT CAR RENTAL — 


MQPUT FLIGHT 
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Reply-to 
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Figure 16-11 Parallel Processing 


The model in Figure 16-11 allows several requests to be sent by an application without 
the application having to wait for a reply to one request before sending the next. All the 
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requests can then be processed in parallel. Designing the system in this way can improve 
the overall response time. Although the application might normally process the replies 
only when they have all been received, the program logic may also specify what to do 
when only a partial set of replies is received within a given period of time. 


16.10 Interfacing with CICS, IMS or batch 


WebSphere MQ is available for a variety of platforms. WebSphere MQ for z/OS includes 
several adapters to provide messaging and queuing support for: 


> CICS 
> IMS 
> Batch or TSO/E 


16.10.1 The WebSphere MQ-CICS bridge 


The WebSphere MQ-CICS bridge enables an application not running in a CICS 
environment to run a CICS program or transaction on CICS and receive a response back. 
This non-CICS application can be run from any environment that has access to a 
WebSphere MQ network that encompasses WebSphere MQ for z/OS. 


The CICS program can be invoked using the EXEC CICS LINK command. 


16.10.2 The WebSphere MQ-IMS bridge 


With help of the WebSphere MQ-IMS bridge it is possible to connect WebSphere MQ 
applications to applications on an IMS system. It enables implicit WebSphere MQ API 
support. This is an easy way to re-engineer legacy applications that were controlled by 
3270-connected terminals. The legacy application does not have to be changed to get 
access to it via WebSphere MQ. The bridge is an IMS Open Transaction Manager Access 
(OTMA) client. 


16.11 Summary 


This unit has discussed at an overview level, the functions and value that WebSphere MQ 
provides. 
We highlighted the five major benefits of WebSphere MQ: 


> There is a common application programming interface, the MQI, that is consistent 
across all the supported platforms. 


> WebSphere MQ can transfer data with assured delivery; messages don't get lost, even 
in the event of a system failure. Just as important, there is no duplicate delivery. 
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> The communicating applications do not have to be active at the same time. For 
example, a sending application can still be putting messages on a queue even though 
the receiving application is not active. 


> Message-driven processing is a style of application design. An application is divided 
into discrete functional modules that can communicate with each other by means of 
messages. In this way, the modules can execute on different systems, be scheduled at 
different times, or they can act in parallel. 


> Application development is made faster by shielding the developer from the 
complexities of the network. 


Furthermore, we can interface with the different subsystems of z/OS. 








Key terms in this chapter 
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16.12 Discussion questions 


Why do you need messaging and Queuing? 
Why would you work asynchronous? 

What is the Queue manager? 

What is the purpose of MQI? 

Why do you need a dead-letter queue? 


OD Be ee 


Why would you need compensation transactions? 
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16.13 Instructor notes 


16.13.1 Answers to 16.12, “Discussion questions” on page 16-18 
1. Why do you need messaging and Queuing? 


— communicate between different existing systems 
— add extensions to the current systems 
— get information from one place to another 


2. Why would you work asynchronous? 


— tobe more independent of others 
— you can process one request after another when you want 


3. What is the Queue manager? 


— the heartbeat of WebSphere MQ, he coordinates everything, the queues, the 
channels, the processes, etc.... 


4. What is the purpose of MQI? 


— to have a simple interface for all users, so that they don’t need to know all the 
network parameters. The network is hidden to them. 
— via the correct calls, the correct information gets treated 


5. Why do you need a dead-letter queue? 


— Mainly to avoid that you lose messages. If your QM does not know what to do 
with a message, it will end up in the dead-letter queue. 

— One of the important factors of MQ is, NOT to lose any messages (at least not 
when they are persistent). the DLQ helps you to achieve that. 


6. Why would you need compensation transactions? 


— some parts of the unit of work may already be executed, when a later part fails. 
— The system flow will not take care of that, since you have intermediate 
syncpoints, so you need to take care of that, yourself. 


16.13.2 Refer to 16.1, “Islands of automation” on page 16-1 
This unit introduces the WebSphere MQ product: 


> We will look at some examples of the types of environments that can make use of 
WebSphere MQ for complete solutions. 

We will compare WebSphere MQ to other communication models. 

We will list the major strengths of the WebSphere MQ asynchronous model. 

The message and queuing interface (MQI) will be introduced. 

We will spend a few moments understanding what a WebSphere MQ message is as 
well as how it is delivered to applications. 


vvvy 
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There is a fairly common mixture of system types. We want the students to understand 
we have a global solution, not just another way to tie IBM systems together and provide a 
little extra non-IBM connectivity on the side. 


Make the point though that many organizations have legacy systems or are running their 
big terabyte databases on mainframes (enterprise servers), so mainframes need to be 
included. 


Hanging it all together is too complex for roll-your-own solutions. Don't hammer this 
one, they all know it, but point out that even big companies full of technical whiz kids 
now say they would rather buy shrink-wrapped solutions. 


Make the point that there are one-off solutions based on OSI, or on TCP/IP using remote 
procedure call (RPC), or on SNA, but that these are either inflexible in the application 
design they permit (X.400, FTAM, SFTP, and Telnet) or need a lot of home-grown design 
and code. 


Finally, it is no good exchanging data unless both sides can agree on what has, and has 
not, transpired, so that their respective databases hold consistent data. For example, if I 
book a hotel room or hire a car, my travel agent needs to know that, when his system 
prints the docket, the other guy's system has updated its database so that, when I arrive, 
the honeymoon suite or rental car is waiting. 


Point out that this may be a joke, but if the deal is worth 5 million dollars of foreign 
exchange, it would not be a joke at all if a transaction from one side could be repudiated 
by the other. Hence we need non-repudiation facilities built in. 


To Figure 16-1 on page 16-2, the main point is to make sure everyone is comfortable 
with the very high-level idea of using messaging and queuing for program-to-program 
communication. If it helps, tell them to consider the queue as a replacement for an 
intermediate file, making sure you point out that queues have certain advantages which 
will be covered as we progress. 


Point out the drawback of this synchronous model is the inherent dependency that 
Program A and Program B must be available. 


16.13.3 Refer to 16.3, “Styles of communication” on page 16-5 
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Step the students through the three styles. 


Examples of the conversational style are APPC, CPI-C, and the sockets interface to 
TCP/IP. Using CPI-C, for example, the complexities of the network are fairly 
well-hidden, but not totally. Some, at least, of the LU6.2 conversation is exposed to the 
application programmer. When a program sends some data to another program and 
expects a reply, it may carry on with other processing for a while. But sooner or later it 
must issue a communications receive which may cause it to wait in a blocked state until 
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the reply arrives. The implication is that the partner program is present and running. In 
this, it is not unlike a telephone conversation; both ends must be there and the line must 
be working for anything useful to happen. 


The call and return style is not dissimilar although, in implementation, it requires that a 
more substantial piece of code be linked to each program. This stub, as it is called, 
transfers control and parameters across the network, normally over TCP/IP. Both the 
calling and the called program work in a synchronous manner, and both partners must be 
executing at the same time. 


The messaging style is the one used by WebSphere MQ. A program communicates with 
another program simply by sending it a message, but there is no requirement for the two 
programs to be active at the same time. 


16.13.4 Refer to 16.4.2, “Queue manager” on page 16-6 


queue manager provides queuing services to applications, and manages the queues that 
belong to it. It ensures that: 


> Object attributes are changed according to the commands received. 

> Special events such as trigger events or instrumentation events are generated when 
the appropriate conditions are met. 

> Messages are put on the correct queue, as requested by the application making the 
MQPUT call. The application is informed if this cannot be done, and an appropriate 
reason code is given. 


Each queue belongs to a single queue manager and is said to be a local queue to that 
queue manager. The queue manager to which an application is connected is said to be the 
local queue manager for that application. For the application, the queues that belong to its 
local queue manager are local queues. A remote queue is a queue that belongs to another 
queue manager. A remote queue manager is any queue manager other than the local 
queue manager. A remote queue manager can exist on a remote machine across the 
network, or might exist on the same machine as the local queue manager. WebSphere 
MQ supports multiple queue managers on the same machine. A queue manager object 
can be used in some MQI calls. For example, you can inquire about the attributes of the 
queue manager object using the MQI call MQINQ. 


To introduce the concepts of a queue manager and a WebSphere MQ object, and to 
describe the MQI calls. 


There are eight major calls: 


MQCONN 
MQCONNX 
MQDISC 
MQOPEN 


vvvy 
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MQCLOSE 
MQPUT 
MQPUTI 
MQGET 


vvvy 


and five more specialized ones: 


MQBEGIN 
MQCMIT 
MQBACK 
MQINQ 
MQSET 


y¥vyyV¥y¥ 


You are advised not to dig into the function here. Simply stress that this simple call set 
provides all the function. Note that MQPUT1 opens a queue, puts a single message on 
the queue, and then closes the queue. It is more efficient if you have only one message to 
send. 


At this point in the course, it is sufficient to consider the following types of WebSphere 
MQ objects: 


The queue manager object 
Queue 

Process 

Namelist 


y¥vyyY 


The first two are self explanatory. A process is used to specify the properties of an 
application that is started automatically by the triggering mechanism. 


A namelist is a WebSphere MQ object that contains a list of other WebSphere MQ 
objects. Typically, namelists are used by applications such as trigger monitors, where 
they are used to identify a group of queues. The advantage of using a namelist is that it is 
maintained independently of applications; it can be updated without stopping any of the 
applications that use it. Also, if one application fails, the namelist is not affected and 
other applications can continue using it. Namelists are also used with queue manager 
clusters to maintain a list of clusters referred to by more than one WebSphere MQ object. 


What is in the MQI? 


The Message Queue Interface consists of the following: 


> Calls through which programs can access the queue manager and its facilities 
> Structures that programs use to pass data to, and get data from, the queue manager 
> Elementary data types for passing data to, and getting data from, the queue manager 


WebSphere MQ for z/OS also supplies: 
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> Two extra calls through which z/OS batch programs can commit and back out 
changes. 

> Data definition files (Sometimes known as copy files, macros, include files, and 
header files) that define the values of constants supplied with WebSphere MQ for 
z/OS. 

> Stub programs to link-edit to your applications. 

> A suite of sample programs that demonstrate how to use the MQI on the z/OS 
platform. 


There are 2 parts in a message: 


The application data in a message is of no concern to the queue manager and is not 
checked or processed. The exception to this is that, under certain circumstances, it may 
be converted from one character representation to another, and from one numeric 
representation to another, if so desired. We shall be looking more closely at application 
data conversion later in the course. 


The message descriptor is used by the queue manager and the receiving application for 
the purposes of security; reporting, determining the sequence in which messages are 
delivered to the receiving application, and so on. Some of the fields in the message 
descriptor are set by the application which puts the message on a queue; others are set by 
the queue manager on behalf of the application. Both the message descriptor and the 
application data are returned to the application which gets the message from the queue. 
Do not get too deep on the contents of the message descriptor or the use of the other 
headers here. They are just starting to learn. We will look at the message descriptor more 
when we review the MQI. 


In general, the default maximum message length is 4 MB, although you can increase this 
to a maximum length of 100 MB (where 1 MB equals | 048 576 bytes. However, some 
early queue managers (such as Unixware) support less while more recent queue 
managers (Version 5 queue managers like Windows NT) support greater. 


So far, we have spoken as if everything is happening on one system. Quite often this will 
be true, but WebSphere MQ is able to connect applications over a network. 


16.13.5 Refer to 16.5.1, “Queue Types” on page 16-10 


Step the students through what happens when Program A puts a message on local queue 
Q1. This is easy, because the queue manager to which Program A is connected owns Q1 
and therefore knows where it is. However, when Program A puts a message on remote 
queue Q2, the queue manager to which Program A is connected needs to know which 
queue manager owns Q2 and where that queue manager is located in the network. This is 
done in various ways which we shall discuss later. Do not be tempted to discuss these 
ways now. Assuming the queue manager knows this information, the message can be 
forwarded to that queue manager and put on the destination queue. 
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However, the delivery of a message to a remote queue needs to be done reliably and once 
only. The queue manager to which Program A is connected identifies a local queue called 
a transmission queue, QX in the figure, and puts the message on that queue. It is then the 
task of a message channel agent (MCA) to get the message from the transmission queue 
and send it to a partner MCA at the other end of a communications connection, for 
example, an SNA LU6.2 conversation or a TCP connection. The receiving MCA then 
puts the message on the destination queue Q2. 


Once the receiving MCA has put the message on the destination queue, the protocol used 
by the two MCAs ensures that the message is removed from the transmission queue. If 
there is a communications failure during transmission, the same protocol also ensures 
that the two ends resynchronize when the communications connection is restored. Any 
messages that have been safely received are removed from the transmission queue at the 
sending end and any messages that were not safely received are sent again. This protocol 
is called the Message Channel Protocol (MCP) and is responsible for ensuring that a 
message is delivered to a remote queue once and once only. 


If a message cannot be delivered, for example, because of an administration error or 
because the queue is full, it would normally be put on the dead letter queue at the 
receiving end, queue DLQ in the figure. However, the sending application may specify 
other options. 


16.13.6 Refer to 16.6, “Channels” on page 16-12 
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Channels are objects that provide a communication path from one queue manager to 
another. Channels are used in distributed queuing to move messages from one queue 
manager to another. They shield applications from the underlying communications 
protocols. The queue managers might exist on the same, or different, platforms. For 
queue managers to communicate with one another, you must define one channel object at 
the queue manager that is to send messages, and another, complementary one, at the 
queue manager that is to receive them. 


The conversational style of program-to-program communication requires the existence of 
a communications connection between each pair of communicating applications. 


In WebSphere MQ, it is the MCAs which are responsible for moving messages from one 
queue manager to another, and so it is only each pair of MCAs that requires a 
communications connection. In this way, one communications connection can support 
multiple applications connected to one queue manager sending messages to multiple 
applications connected to another queue manager. 
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16.13.7 Refer to 16.7, “Data integrity” on page 16-13 


The purpose is to show how a business transaction can be implemented as multiple 
asynchronous units of work using WebSphere MQ, and to compare this with the more 
traditional approach of using a single distributed unit of work. 


The conversational style of program-to-program communication normally uses a 
two-phase commit protocol to ensure that changes to databases are synchronized. But a 
two phase commit protocol involves the locking of resources across a network and, 
across a large and complex network of databases, this becomes difficult to plan for and 
can lead to performance problems. Ask the students to imagine the amount of locking 
required and the possible impact on performance. 


You may be asked what happens if the database update in unit of work 3 fails for any 
reason. The answer is that unit of work 3 would need to send a message back to the 
originating system requesting that the database update made in unit of work 1 be rolled 
back. This is known as a compensating transaction. 


16.13.8 Refer to 16.8, “Security” on page 16-15 


It is easy to be tempted but resist the urge to say more than that a message can be 
accompanied by a user ID and other context information which can be interrogated at 
each stage of its journey. 


WebSphere MQ queue managers transfer information that is potentially valuable, so you 
need to use an authority system to ensure that unauthorized users cannot access your 
queue managers. Consider the following types of security controls: 


Who can administer WebSphere MQ: You can define the set of users who can issue 
commands to administer WebSphere MQ. 


Who can use WebSphere MQ objects: You can define which users (usually 
applications) can use MQI calls and PCF commands to do the following: 
> Who can connect to a queue manager. 


> Who can access objects like queues, namelists, processes, and authentication 
information objects, and what type of access they have to those objects. 


> Who can access WebSphere MQ messages. 
> Who can access the context information associated with a message. 
Channel security You need to ensure that channels used to send messages to remote 


systems can access the required resources. You also need to ensure that channels can only 
be manipulated by authorized users. 
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You can use standard operating facilities to grant access to program libraries, MQI link 
libraries, and commands. However, the directory containing queues and other queue 
manager data is private to WebSphere MQ; do not use standard operating system 
commands to grant or revoke authorizations to MQI resources. 


16.13.9 Additional information 


You could also talk about persistency: not all messages are kept in case of failure. We 
could talk about triggering, because that is also available in MQ. But we mainly wanted 
to give a global view of the Product. We did not even specify how you can define 
everything on z/OS, because most of those screen, the system administrator passes them 
once, at the installation. If the students want to know more, they can look to whatever 
platform, the terminology is the same but they may be able to practice a bit. 


16.13.10 Refer to 16.9, “Online example” on page 16-16 
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To explain how WebSphere MQ enables applications to be built in which units of 
processing can be done in parallel, and perhaps even on different systems. 


A more complex application may involve sending a number of requests to different 
servers. For example, a travel agent might use an application to arrange a trip for a 
customer. The requirements of the customer might mean that the application needs to 
make a number of requests - to make an airline reservation, to book a hotel room, to run a 
credit check, and so forth. 


By using queues, these steps do not have to be performed serially. The requests can be 
put on different queues, and processed in parallel. 


The application might then wait until it has received all the replies before preparing a 
consolidated response. Alternatively, the business logic may define a time limit to wait 
for the replies. In that case, the application may present some form of partial response 
with limited information after that time has elapsed. 


As we have seen previously, the application design may involve having a separate 
process to receive and process the replies. 
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Making applications available 
on the system 


In this part we reveal the i inner workings of z/OS with discussions of system libraries, 
-This part also includes advanced topics on 


starting and stoppin a system, canine clustering of multiple systems, and-asing- 
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System libraries and 
system programming 








Objective: 
As a2z/OS system programmer you will need to know how z/OS works 


In this chapter, you will learn: 


> An overview of z/OS system programming 
> System libraries, their use and methods for managing their content. 

















17.1 Considerations for a new application 


When a new application needs to be added to a system a number of tasks need to be 
performed before the application can be used by end users. A production control analyst 
will be needed to add batch applications into the batch scheduling package, add the new 
procedures to a procedure library and set up all the operational procedure. A systems 
programmer will need to do tasks concerned with the system itself such as setting up 
security privileges and adding the programs to system libraries. A systems programmer 
will also be involved with setting up any automation for the new application. If a system 
reload is necessary to implement the application then Operations staff will need to IPL 
the system. 
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The system programmer can fulfil several roles and in a large installation there may be a 
division of duties. The following roles and more exist: 


z/OS system programmer 
CICS system programmer 
Database system programmer 
Database administrator 
Network system programmer 
Automation specialist 
Security manager 

Hardware management 


vvvvvvvyy 


In addition to these highly skilled roles, there are other skilled jobs that need to be 
performed: 


> Production control analyst 
System operator 

Network operator 
Security administrator 
Service manager 


vvvy 


17.2 What is system programming? 


17-2 


The role of the system programmer is to install, customize, and maintain the operating 
system. The z/OS operating system runs on various hardware configurations. A system 
programmer must also define the hardware I/O configuration resources that are to be 
available to the operating system. The hardware can be used in two modes: 


> Basic mode A central processor mode that does not use logical partitioning. With one 
central processor, one copy of the z/OS operating system runs in the machine. 


> LPAR mode Logically partitioned (LPAR) mode, which is a central processor 
complex (CPC) power-on reset mode that enables use of the PR/SM feature and 
allows an operator to allocate CPC hardware resources (including central processor 
central storage, expanded storage, and channel paths) among logical partitions. A 
z/Series operating system runs in each LPAR in the machine, but not necessarily z/OS 
in each one. 


Hardware is discussed further in Chapter 22, “Hardware systems and LPARs” . 


A z/OS system programmer must be aware of the following: 


> Storage concepts 

> Device I/O configurations 

> Processor configurations 

> Console definitions 

> System libraries where the software is placed 
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> System data sets and their placement 
> Customization parameters that are used to define your z/OS configuration 
> Security admistration 


A single systems programmer will not necessarily cover all these duties. There is often a 
“separation of duties”. This is usually an audit requirement so that one person does have 
too much power on a system. On a test system however a single person may have to 
perform all the roles including being the operator and this is often the best way to learn 
how everything works. 
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Figure 17-1 System programming overview 


z/OS system programming covers the following areas: 
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17.2.1 z/OS operational system administration 


> Customization parameters that are used to define the z/OS configuration 

> z/OS implementation and maintenance 

> System libraries where the software is located and System data sets and their 
placement 

> z/OS System address spaces and subsystems controlling (*MASTER*, JES2, 
CATALOG, etc) 

> Real and virtual storage considerations when installing and customizing a z/OS 
operating system environment. 


17.2.2 Workload Management 


Workload Manager provides a solution for managing workload distribution, workload 
balancing, and distributing resources to competing workloads. Workload Manager is the 
combined cooperation of various subsystems (CICS, IMS/ESA®, JES, APPC, TSO/E, 
z/OS UNIX System Services, DDF, DB2, SOM®, LSFM, and Internet Connection 
Server) with the Workload Manager (WLM) z/OS component. WLM is a policy driven 
task and there are often different policies at various times of the day. For example there 
may be a daytime policy where online tasks have priority and a nighttime policy where 
batch jobs are more important. 


17.2.3 System performance 


The task of tuning a system is an iterative and continuous process and is the discipline 
that most directly impacts all users of system resources in an enterprise. The controls 
offered by WLM are only one aspect of this process. Initial tuning consists of selecting 
appropriate parameters for various system components and subsystems. Once the system 
is operational and criteria have been established for the selection of jobs for execution via 
job classes and priorities, WLM will control the distribution of available resources 
according to the parameters specified by the installation. 


WLM, however, can only deal with available resources. If these are inadequate to meet 
the needs of the installation, even optimal distribution may not be the answer; other areas 
of the system should be examined to determine the possibility of increasing available 
resources. 


When requirements for the system increase and it becomes necessary to shift priorities or 
acquire additional resources, such as a larger processor, more storage, or more terminals, 
the WLM parameters might have to be adjusted to reflect changed conditions. 


17.2.4 Job flow 
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z/OS uses a job entry subsystem (JES) to receive jobs into the operating system, to 
schedule them for processing by z/OS, and to control their output processing. JES is the 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15pm Chapter17 system programming tasks.fm 


component of the operating system that provides supplementary job management, data 
management, and task management functions such as scheduling, control of job flow, 
and spooling. 


17.2.5 I/O device management 


The I/O configuration to the operating system (software) and the channel subsystem 
(hardware) must be defined. The Hardware Configuration Definition (HCD) component 
of z/OS consolidates the hardware and software I/O configuration processes under a 
single interactive end-user interface. The output of HCD is an I/O definition file (IODF), 
which contains I/O configuration data. An IODF is used to define multiple hardware and 
software configurations to the z/OS operating system. When a new IODF is activated, 
HCD defines the I/O configuration to the channel subsystem and/or the operating system. 
With the HCD activate function or the z/OS ACTIVATE operator command, changes can 
be made in the current configuration without having to initial program load (IPL) the 
software or power-on reset (POR) the hardware. Making changes while the system is 
running is known as dynamic configuration or dynamic reconfiguration. 


17.2.6 Security 


Data security is the protection of data against unauthorized disclosure, transfer, 
modification, or destruction, whether accidental or intentional. A security system must be 
installed in the operating system by a system programmer to maintain the resources 
necessary to meet the security objectives. The system programmer has the overall 
responsibility, using the technology available, to transform the objectives of the security 
policy into a usable plan. 


17.2.7 Integrity 


An operating system is said to have system integrity when it is designed, implemented 
and maintained to protect itself against unauthorized access, and does so to the extent that 
security controls specified for that system cannot be compromised. Specifically for z/OS, 
this means that there must be no way for any unauthorized program, using any system 
interface, defined or undefined: 


> To obtain control in an authorized state 
> To bypass store or fetch protection 
> To bypass OS password, VSAM password, or RACF security checking 


17.2.8 Availability 


The software products supporting system programmers and operators in managing their 
systems heavily influence the complexity of their job and their ability to keep system 
availability at a high level. 
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Many installations need to ensure that their system and its services are available and 
operating to meet service level agreements. Installations with 24-hour, 7-day operations 
need to plan for minimal disruption of their operation activities. In terms of z/OS 
operations, how the installation establishes console recovery or whether an operator must 
re-IPL a system to change processing options are important planning considerations. 


17.2.9 Change Control 


All change creates risk and one of the advantages of the mainframe is the very high 
availability. All change must therefore be carefully controlled and managed. A high 
proportion of any system programmer’s time is involved in the planning and risk 
assessment of change. The most important item of any change is how to reverse it and go 
back to the previous situation. 


I/T organizations achieve their goals through disciplined change management processes 
and policy enforcement. The goals include: 


high service availability 
increased security 

audit readiness 

cost savings 


vvvy 


17.2.10 z/OS Operation 


17-6 


Operating z/OS involves managing hardware such as processors and peripheral devices 
(including the consoles where your operators do their work) and software such as the 
z/OS operating control system, the job entry subsystem, subsystems such as NetView that 
can control automated operations, and all the applications that run on z/OS. 


The operation of a z/OS system involves the following: 


> Message and command processing that forms the basis of operator interaction with 
z/OS and the basis of z/OS automation. 

> Console operations or how operators interact with z/OS to monitor or control the 
hardware and software. 


Planning z/OS operations for a system must take into account how operators use consoles 
to do their work and how to manage messages and commands. Because messages are 
also the basis of automated operations, understanding message processing in a z/OS 
system can help the system programmer to plan z/OS automation. 


In thinking about operator tasks, an installation needs to consider how to manage 
messages and commands. Operators need to respond to messages. Routing messages to 
operator consoles, suppressing messages to help the operators manage increased message 
traffic, or selecting messages for automated operations can all help to manage system 
activity efficiently. 
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Controlling operating activities and functions 

As more installations make use of multisystem environments, the need to coordinate 
the operating activities of those systems becomes crucial. Even for single z/OS 
systems, an installation needs to think about controlling communication between 
functional areas (such as a tape-pool library and the master console area, for 
example). In both single and multisystem environments, the commands operators can 
issue from consoles can be a security concern that requires careful coordination. As a 
planner, the system programmer needs to make sure that the right people are doing 
the right tasks when they interact with z/OS. 


Simplifying operator tasks 
Because the complexity of operating z/OS has increased, an installation needs to 
think about the tasks and skills of its operators. How operators respond to messages at 
their consoles and how to reduce or simplify their actions are important to operations 
planning. Also, the installation needs to plan z/OS operator tasks in relation to any 
automated operations that help simplify those tasks. 


17.2.11 z/OS Production Control 


Production control usually involves specialist staff to manage batch scheduling, using a 
tool such as Tivoli Workload Scheduler, to build and manage a complex batch schedule. 
This may involve daily and weekly backups running at particular points within a 
complex sequence of application suites. Databases and online services may also be taken 
down and brought back up as part of the schedule. Changes need to be made to 
accomodate public holidays and other special events such as a winter sale. 


Production control are also responsible for taking a developer’s new program and 
releasing it to production. This would typically involve moving the source code to a 
secure production library, recompiling the code to produce a production load module and 
placing that module in a production load library. JCL would also be copied and amended 
to production standards and placed in appropriate procedure libraries and application 
suites added to the job scheduler. There may also be an interaction with the system 
programmer if a new library needs to be added to the linklist or authorized. 
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17.3 z/OS System Libraries 
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z/OS software 





Customization data 





Non-z/OS (CICS, DB2) 


User defined exits 





ae 


Non-IBM software 


User data 


Figure 17-2 Types of data 
As can be seen in Figure 17-2 there are several different type of data within a system. 


Firstly there is the z/OS software as supplied by IBM. This is usually installed to a series 
of disk volumes know as the system residence volumes (SYSRES). Some years ago the 
software all fitted on one 3390 volume but over the years this has grown so that most 
installation have a minimum of two SYSRES volumes in a SYSRES set. Much of the 
flexibilty of z/OS is built around these SYSRES sets as maintenance can be applied to a 
new set which is cloned from the production set whilst the current set is running 
production work. A short outage can then be taken to IPL from the new set and the 
maintenance has been implemented. Also the change can be backed out by IPLing from 
the old set. Fixes to z/OS are managed by a product called SMP/E (System Management 
Program/Extended). Indirect cataloging using system symbols is used so that a particular 
library is cataloged as being on say sysres volume 2 and the name of that volume is 
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resolved by the system at IPL time from the system symbols. Symbols are discussed in 
17.6, “System symbols” on page 17-25 


The next group of volumes are the non-z/OS and non-IBM software volumes. These may 
be combined into one group. The majority of non-z/OS software is not usually on the 
SYSRES volumes as the SYSRES sets are usually managed as one entity by SMP/E. The 
other software is usually managed seperately. These volumes do not form part of the 
SYSRES sets and therefore there is only one copy each library. As many volumes as 
required can be added to this group each with an individual disk name. 


Customization data is items such as SYSI.PARMLIB, SYS1.PROCLIB, the master 
catalog, the IODF, page datasets, JES spool and other items essential to the running of the 
system. It is also the place where SMP/E data is stored to manage the software. These 
data sets are not always located on separate dasd volumes to the IBM supplied z/OS 
software. Some installations place the PARMLIB and PROCLIB on the first sysres pack, 
others place them on the master catalog pack. This is a matter of choice and depends how 
the sysres volumes are managed. A particular installation will have a preferred method. 


On many systems some of the IBM supplied defaults are not appropriate so they need to 
be modified. User exits and user modifications (usermods) are made to IBM code so that 
it will behave as the installation requires. The modifications are usually managed using 
SMP/E. Some customization can be obligatory, for example DFSMSrmm almost always 
requires user exit EDGUX100 to be customized and many installations modify language 
environment defaults. But many installations are trying to get away from major 
customization and wish to run a “vanilla” system as this is easier to manage during 
upgrades. 


Finally comes the user data which is usually the largest pool of disk volumes. This is not 
part of the system libraries but is presented here for completeness. This will contain 
production, test and user data. It is often split into pools and managed by SMS (System 
Managed Storage) which can target data to appropriately managed volumes. For example 
production data can be placed on volumes which are backed up daily, whereas user data 
may only be captured weekly and may be migrated to tape after a short period of 
inactivity to free up the disk volumes for further data. 


z/OS has many standard system libraries such as the following: SYS1.PROCLIB, 
SYS1.PARMLIB, SYS1.LINKLIB, SYS1.LPALIB and SYS1.NUCLEUS. Some of 
them are related to the IPL processing, others to the search order of invoked programs or 
to system security. 


SYS1.PROCLIB contains JCL procedures distributed with z/OS. SYS1.PARMLIB 
contains control parameters for the whole system. SYS1.LINKLIB has many execution 
modules of the system. SYS1.LPALIB contains the system execution modules that are 
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loaded into the link pack area when the system initializes. SYS1.NUCLEUS has the 
basic supervisor modules of the system. 


All the required system datasets are prefixed with SYS1. SYS1 is a required node and 
must be in the master catalog. By default there is no SYS2 or any others and an 
installation is free to use any prefix it likes, within the naming rules. Many independent 
software vendors ship their products with a particular prefix but each installation usually 
has rules about naming conventions. I have seen SYS3 used for all third party software 
and also seen SYS1 used for all software. However rules within the security package 
must be set up for all these data sets and auditors usually frown upon rules which allow a 
universal read to SYS1. 


17.3.1 SYS1.LINKLIB 


This section explains the LNKLST concatenation and the related mechanisms in z/OS 
for improving the performance of locating and fetching modules. 


The LNKLST is a group of system and user-defined load libraries which form part of the 
search order the system uses for programs. 


SYSI.LINKLIB must reside in a direct access volume, which can be the system 
residence volume. All the LNKLST libraries must be allocated exclusively with primary 
extents. Otherwise, updates to a LNKLST dataset might cause the dataset to expand into 
an extent that did not exist when the LNKLST set was defined. A subsequent attempt to 
access a member in the new extent causes the requesting program to abend with an I/O 
error. 


System’s Search Order for Programs 

Modules (programs) must be loaded into virtual storage and central storage before they 
can be run. When one module calls another module, either directly by asking for it to be 
run or indirectly by requesting a system service that uses it, does not begin to run 
instantly. How long it takes before a requested module begins to run depends on where in 
its search order the system finds a usable copy and how long it takes the system to make 
the copy it finds available. 


When a program is requested through a system service, the system searches for it in the 
following sequence: 


> STEPLIB or JOBLIB: these are specific DD names that can be used to allocate 
datasets to be searched. STEPLIB is specified for a specific job step and JOBLIB for 
the whole job. 


Example 17-1 STEPLIB specification 
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//PAYROLL JOB BROWN,MSGLEVEL=1 
//STEP1 EXEC PROC=LAB14 
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//STEP2 EXEC PGM=SPKCH 
//STEPLIB DD DSNAME=PRIV.LIB5,DISP=(OLD, KEEP) 
//STEP3 EXEC PGM=TIL80 
//STEPLIB DD DSNAME=PRIV.LIB12,DISP=(OLD, KEEP) 


The system searches PRIV.LIBS for the program SPKCH and PRIV.LIB2 for TIL80. 


> Link Pack Area (LPA). LPA modules are loaded in common storage and shared by all 
address spaces in the system. The LPA is searched in this order: 
— Dynamic LPA modules. 
— Fixed LPA (FLPA) modules. 
— Modified LPA (MLPA) modules. 
— Pageable LPA (PLPA) modules. 


> Libraries in the linklist. By default, the linklist begins with SYS1.LINKLIB, 
SYS1.MIGLIB and SYS1.CSSLIB. However, this order may be changed or add 
other libraries to the linklist concatenation. The system must bring modules found in 
the linklist into private area virtual storage before the programs can run. 


This last element of the sequence is called LNKLST concatenation and can be seen in 
Figure 18-2 on page 391. 
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Figure 17-3 Overview of the LNKLST 


Using PROGxx to define LNKLST Concatenations 

A LNKLST set consists of an ordered list of datasets for processing as the LNKLST 
concatenation. Every LNKLST set contains the LINKLIB, MIGLIB, and CSSLIB 
datasets as the first datasets in the LNKLST concatenation. Unless overridden by 
SYSLIB statements, every LNKLST set begins with SYS1.LINKLIB, SYS1.MIGLIB 
and SYS1.CSSLIB. The system automatically adds these datasets to the beginning of the 
LNKLST set that you define. 


The PROGxx parmlib member contains four statement types: APF, EXIT, SYSLIB, and 
LNKLST. ZNKLST statements control the definition and activation of the LNKLST set 
that forms the LNKLST concatenation. SYSLIB statements are used when you want to 
change the default system datasets that are placed at the beginning of the LNKLST 
concatenation (or LPALST concatenation). 


Use the LNKLST statement: 


> To define the LNKLST set. 
> To add a dataset to the LNKLST set. 
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> To delete a dataset from the LNKLST set. 

To remove the definition of a LNKLST set from PROGxx (valid only after IPL). 

> To test for the location of a routine associated with one of the datasets in the LNKLST 
set (valid only after IPL). 

> To indicate that a LNKLST set is to be activated. 


Vv 


At IPL, ensure that you have a LNKLST ACTIVATE statement for the LNKLST set that 
you have defined, and specify PROG=xx in IEASYSxx. 


You can define multiple LNKLST sets, but only one LNKLST set is current in the system 
at any time. You can change the current LNKLST set dynamically through the SET 
PROG=xx and SETPROG LNKLST commands. A LNKLST set remains allocated until there 
are no longer any jobs or address spaces associated with it. If the current LNKLST set is 
dynamically changed, any job or address space associated with the previous LNKLST set 
continues to use the datasets until the job or address space finishes processing. Thus, a 
previously current LNKLST set might be active or in use by a job or address space even 
though a new current LNKLST set has been activated. Jobs or address spaces that are 
started after the new current LNKLST set is activated use the new current LNKLST set. 


You can place LNKLST statements for a LNKLST set in different PROGxx members. 
For example, you can specify PROG=(01,02,03) and place the LNKLST DEFINE 
statement in PROGOI, LNKLST ADD statements in PROGO2, and the LNKLST 
ACTIVATE statement in PROGO3. 


Let’s see an example of a PROGxx member which defines a LNKLST set NEWLLSET, 
adds datasets to it and activates it: 


Example 17-2. PROGxx member with LNKLST statements 


LNKLST DEFINE NAME(LNKSYSA) COPYFROM(CURRENT) 
LNKLST ADD NAME(LNKSYSA) DSNAME(SYS1.PROD.LOADLIB) 
LNKLST ADD NAME(LNKSYSA) DSNAME(SYS1.TEST.LOADLIB) 
LNKLST ACTIVATE NAME(LNKSYSA) 


Library lookaside (LLA) 


Library lookaside (LLA) is an address space that maintains a copy of the directory entries 
of the libraries that it manages. Since the entries are cached, the system does not need to 
read the data set directory entries to find out where a module is stored before fetching it 
from DASD. This greatly reduces I/O operations. 


So, the main purpose of using LLA is to improve the performance of module fetching on 
your system. 


LLA improves module fetch performance in the following ways: 
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> By maintaining (in the LLA address space) copies of the library directories that the 
system uses to locate load modules. The system can quickly search the LLA copy of a 
directory in virtual storage instead of using costly I/O to search the directories on 
DASD. 

> By placing (or staging) copies of selected modules in a virtual lookaside facility 
(VLF) data space DCSVLLA. The system can quickly fetch modules from virtual 
storage, rather than using slower I/O to fetch the modules from the DASD. 

> By determining which modules, if staged, would provide the most benefit to module 
fetch performance. LLA evaluates modules as candidates for staging based on 
statistics it collects about the members of the libraries it manages (such as module 
size, frequency of fetches per module or fetch count, and the time required to fetch a 
particular module). 


Before you can use LLA, you have to do the following: 


> Determine which libraries should be LLA-managed libraries. 

> Code the CSVLLAxx parmlib member to include, modify, and remove the 
LLA-managed libraries. You use the CSVLLAxx parmlib member to specify which 
libraries (in addition to the LNKLST concatenation) library lookaside is to manage. 

> Learn how to control the LLA through the operator commands START, STOP, and 
MODIFY LLA. 


By default, LLA address space caches directory entries for all the modules in the data 
sets included in the /inklist concatenation. You can also identify other user-defined load 
libraries that contain frequently used modules to be managed by LLA. 


Virtual lookaside facility (VLF) 

The virtual lookaside facility (VLF) is a set of services that can improve the response 
time of applications that must retrieve a set of data for many users. VLF creates and 
manages data spaces to store an application's most frequently used data. When the 
application makes a request for data, VLF checks its data space to see if the data is there. 
If the data is present, VLF can rapidly retrieve it without requesting I/O to DASD. 


In order to exploit VLF, an application must identify the data it needs to perform its task. 
The data is known as a data object. 


Certain IBM products or components such as LLA, TSO/E and RACF use VLF to 
improve performance. 


17.3.2 Libraries and Members at IPL time 


SYS1.PARMLIB is a required partitioned data set that contains IBM-supplied and 
installation-created members, which contains list of system parameters values. 
SYS1.PARMLIB must reside in a direct access volume, which can be the system 
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residence volume. It is the most important data set in a z/OS operating system and may 
be viewed a performing a similar function to /etc on a unix system. 


The purpose of the parmlib is to provide many initialization parameters in a pre-specified 
form in a single data set, and thus minimize the need for the operator to enter parameters. 


All parameters and members of the SYS1.PARMLIB data set are described in z/OS MVS 
Initialization and Tuning Reference manual, SA22-7592. Some of the most important 
parmlib members are discussed following in this section. 


LOADxx member 


The most basic level of control of the IPL process is through the LOAD Parameter 
(LOADPARM) on the hardware console. This is an eight-character value made up of four 
fields. Let’s have a look at the first two fields: 


> The first four characters specify the hexadecimal address for the device that contains 
the I/O Definition File (ODF) VSAM data set. This is also the device on which the 
search for the LOADxx member begins. 

> The next two characters are the suffix of the quoted LOADxx parmlib member. If the 
operator does not select a LOADxx member on the system console, the system uses 
LOADOO. 


During IPL, the system looks for LOADxx in the following order: 


> SYSO.IPLPARM through SYS9.IPLPARM on the IODF volume. 
> SYS1.PARMLIB on the IODF volume. 
> SYS1.PARMLIB on the SYSRES volume. 


The LOADxx member specifies: 


> Information about your I/O configuration as specified by the IODFxx suffix. If 
SYS1.PARMLIB contains one or more LOADxx members that point to IODFs, you 
must place SYS1.PARMLIB on the volume that contains those IODFs or on the 
system residence volume. 

> The name of the master catalog with SYSCAT statement. 

> Additional parmlib datasets that the system will use to IPL. The parmlib 
concatenation is a set of up to 16 partitioned datasets defined through the PARMLIB 
statements in the LOADxx member of either SYSn.IPLPARM or SYS1.PARMLIB. 
SYS1.PARMLIB makes the 17th or last dataset in the concatenation and is the default 
parmlib concatenation if no PARMLIB statements exist in LOADxx. This 
concatenation is called /ogical parmlib. In the following figure you may look at the 
definition of a logical parmlib and other LOADxx statements. The search order for 
the system parameters begins with the library in the first PARMLIB statement and 
ends with SYS1.PARMLIB. The benefit of using parmlib concatenation is that it 
gives you greater flexibility in managing parmlib and changes to parmlib members. 
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Loadxx 


IODF 
SYSCAT 


00 SYS6 MOEMVSP1 01 Y 
MPAT1113CATALOG.MCAT.VMPCAT 1 


HWNAME  P201 

LPARNAME A1 

PARMLIB SYSO0O.IPLPARM 

PARMLIB SYS1.0S390R7.PARMLIB 
PARMLIB SYSPROG.SYS1.PARMLIB 





Parmlib concatenation 


SYSO.IPLPARM Search 
SYS1.0S390R7.PARMLIB order 


SYSPROG.SYS1.PARMLIB 
SYS1.PARMLIB 





Figure 17-4 Defining a logical parmlib 
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The IEASYSxx parmlib members that the system is to use. The SYSPARM statement 
identifies one or more IEASYSxx members of the parmlib concatenation that the 
system is to use (in addition to IEASYS00). In z/OS, you can specify system 
parameters using a combination of IEASYSxx parmlib members and operator 
responses to the SPECIFY SYSTEM PARAMETERS message. You can place system 
parameters in the IEASYS00 member or in one or more alternate system parameter 
lists (EAS YSxx). IEASYS00 is the most likely place to put installation defaults or 
parameters that will not change from IPL to IPL. The system programmer can add or 
modify parameters in IEASYSO00. The alternate IEASYSxx members, in contrast, 
should contain parameters that are subject to change, possibly from one work shift to 
another. Another consideration is when the parmlib is shared by multiple systems. It 
is then likely that a each system will have its own IEASYSxx member to define the 
differences and will share the IEASYS00 for any common definitions. The 
availability of system symbols described later has greatly eased the use of shared 
parmlibs. 
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IEASYSxx 

As previously mentioned, you can specify system parameters using a combination of 
IEASYSxx parmlib members and operator responses to the SPECIFY SYSTEM 
PARAMETERS message. Use of the IEASYS00 or IEASYSxx members can minimize 
operator intervention at IPL. Because IEASYS00 is read automatically, the operator can 
respond to SPECIFY SYSTEM PARAMETERS with ENTER or U and need not enter 
parameters unless an error occurs and prompting ensues. On many commercial systems 
the operator is never prompted for parameters at IPL as the required options are all 
predefined. This option is set in the LOADPARM which is discussed in chapter 22. 


The use of system parameters lists in parmlib offers two main advantages: 


> The parameter lists shorten and simplify the IPL process by allowing the installation 
to preselect system parameters. 
> The parameter lists provide flexibility in the choice of system parameters. 


You can do one of the following to specify a parameter list other than IEASYS00 for an 
IPL: 


> Have the operator specify the suffix of an alternate IEASYSxx member by replying 
SYSP=xx in response to the SPECIFY SYSTEM PARAMETERS message. 

R 00,SYSP=xx 

> Specify one or more suffixes of alternate IEASYSxx members on the SYSPARM 
parameter in the LOADxx parmlib member, as previously said. 


Depending on where you specify the suffixes of IEASYSxx members that the system is 
to use, the system overrides or concatenates the members: 


> Ifyou specify the suffixes in LOADxx, the system concatenates the members 
according to the scheme shown in the following table. 

> If you specify the suffixes in LOADxx and the operator specifies the suffixes at IPL, 
the suffixes specified override suffixes in LOADxx. 


The system always processes the IEASYSO0 member first, regardless of where you 
specify IEASYSxx suffixes. If the same parameter appears in both IEASYSO00 and a 
specified alternate IEASYSxx list, the value in the alternate list overrides the value in 
IEASYS00. Also, a parameter value in a later specified IEASYSxx list overrides the 
same parameter in an earlier specified list 


Chapter 17. System libraries and system programming 17-17 


Chapter17 system programming tasks.fm Draft Document for Review December 3, 2004 3:15 pm 


Table 17-1 Precedence of System Parameter Specifications 


concatenation 


Note: “None” means that one of the following occurred: 

No IEA10A prompt was issued 

You responded to IEA101A with a null value 

You responded to IEA101A but you did not specify a SYSP in the response 





For more details of the system parameters that can be placed in an IEASYSxx or 
IEASYSO00 member, see Chapter 46 in z/OS MVS Initialization and Tuning Reference 
manual, SA22-7592. 


PARMLIB commands 


The use of commands enables installations to display the current logical parmlib, display 
general IPL information, and change the current logical parmlib settings. 
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D PARMLIB 
IEE2511 17.12.07 PARMLIB DISPLAY 377 
PARMLIB DATA SETS SPECIFIED 
AT IPL 
ENTRY FLAGS VOLUME DATA SET 
S TOTSY1 SYS1.SYSPROG.PARMLIB 
D TOTSY1 SYS1.PARMLIB 
S ZO4CAT CPAC.PARMLIB 
S ZO4RE1 SYS1.IBM.PARMLIB 


D IPLINFO 

IEE2541 17.15.29 IPLINFO DISPLAY 379 
SYSTEM IPLED AT 09.28.14 ON 07/23/2004 
RELEASE z/OS 01.04.00 LICENSE = z/OS 
USED LOADR2 IN SYSO.IPLPARM ON 3800 
ARCHLVL = 2 MTLSHARE = N 

IEASYM LIST = XX 

IEASYS LIST = (R3,04) (OP) 

IODF DEVICE 3800 

IPL DEVICE 8038 VOLUME ZO04RE1 





Figure 17-5 Commands to display parmlib information after IPL 


The commands are: 


> DISPLAY PARMLIB 


This command display the logical parmlib setup for the [PLed system. A sample output is 
shown in Figure 17-5. 


> SETLOAD xx, PARMLIB 


The following command allows the installation to dynamically change a parmlib 
concatenation without having to IPL. The SETLOAD command specifies the LOADxx 
member that contains the PARMLIB statements to use for the switch. 


> DISPLAY IPLINFO 
This command displays the general IPL information used by the system. The output 
includes the date and time of the IPL, release level, LOADxx information, and what 


IEASYSxx parmlib members were used. A sample output of this command is also shown 
in Figure 17-5. 
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17.4 SYS1.LPALIB 


The link pack area (LPA) is a section of the common area of an address space. It exists 
below the system queue area (SQA) and consists of the pageable link pack area (PLPA), 
then the fixed link pack area (FLPA), if one exists, and finally the modified link pack area 
(MLPA). 


Link pack area (LPA) modules are loaded in common storage, shared by all address 
spaces in the system. Because these modules are reentrant and are not self-modifying, 
each can be used by a number of tasks in any number of address spaces at the same time. 
Modules found in LPA do not need to be brought into virtual storage because the are 
already in virtual storage. 


Modules placed anywhere in LPA are always in virtual storage, and modules placed in 
FLPA are also always in central storage. LPA modules must be referenced very often to 
prevent their pages from being stolen. When a page in LPA (other than in FLPA) is not 
continually referenced by multiple address spaces, it tends to be stolen. 


17.4.1 Pageable link pack area (PLPA) 


17-20 


The PLPA is an area of common storage which is loaded at IPL time (when a cold start is 
done and CLPA option is specified). This area contains read-only system programs, 
along with any read-only reenterable user programs selected by an installation that can be 
shared among users of the system. The PLPA and extended PLPA contain all members of 
SYS1.LPALIB and other libraries that are specified in the active LPALSTxx through the 
LPA parameter in the IEASYSxx or from the operator’s console at system initialization 
(this would override the parmlib specification). 


You may use one or more LPALSTxx members in the SYS1.PARMLIB to concatenate 
your installation’s program library data sets to SYS1.LPALIB. You can also use the 
LPALSTxx member to add your installation’s read-only reenterable user programs to the 
pageable link pack area (PLPA). The system uses this concatenation, which is referred to 
as the LPALST concatenation, to build the PLPA during nucleus initializing process. 
SYS1.LPALIB must reside in a direct access volume, which can be the system residence 
volume. 


Look at Figure 17-6 on page 17-21 for an example of LPALSTxx member. 


On each record, place a string of data set names separated by commas. If a data set is not 
cataloged in the system master catalog, but is cataloged in a user catalog, specify in 
parentheses the one to six character VOLSER of the pack on which the data set resides. 
Continuation is indicated by placing a comma followed by at least one blank after the last 
data set name on a record. 
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File Edit Edit_Settings Menu Utilities Compilers Test Help 


EDIT SYS1.PARMLIB(LPALSTS5B) - 01.01 Columns 00001 00072 
Command ===> Scroll ===> CSR 





000001 SYS2.LPALIB, 

000002 SYS1.LPALIB, 

000003 SYS1.SERBLPA, 

000004 SDF2.V1R4M0.SDGILPA, 
000005 SYS1.SIATLPA, 

000006 ING.SINGMOD3, 

000007 NETVIEW.SCNMLPA1, 
000008 REXX.V1R3M0.SEAGLPA, 
000009 ISF.SISFLPA, 

000010 EOY.SEOYLPA, 

000011 SYS1.SBDTLPA, 

000012 CEE.SCEELPA, 





Figure 17-6 Example of LPALST parmlib member 


17.4.2 Fixed link pack area (FLPA) 


The FLPA is loaded at IPL time, with those modules listed in the active IEAFIXxx 
member of SYS1.PARMLIB This area should be used only for modules that significantly 
increase performance when they are fixed rather than pageable. The best candidate for 
the FLPA are modules that are infrequently used but are needed for fast response. 


Modules from the LPALST concatenation, the LNKLST concatenation, SYS1.MIGLIB, 
and SYS1.SVCLIB can be included in the FLPA. FLPA is selected through specification 
of the FIX parameter in IEASYSxx, which is appended to IEAFIX to form the IEAFIXxx 
parmlib member, or from the operator’s console at system initialization. 


In Figure 17-7 on page 17-22, you may look at a IEAFIX parmlib member: part of the 
modules for FLPA belong to SYS1.LPALIB library. 
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File Edit Edit_Settings Menu Utilities Compilers Test Help 


EDIT SYS1.PARMLIB(IEAFIX01) - 01.01 Columns 00001 00072 
Command ===> Scroll ===> CSR 
BEREEEE NOOO EERE OOOTEE EERE TOD. Of Datg SHAH AE HERR E RRR IIIIAARE RRR IIAAARERE 
000001 INCLUDE LIBRARY(SYS1.LPALIB) 

000002 MODULES (IEAVAROO, /* 7K RCT INIT/TERM */ 
000003 IEAVARO6, /* RCT INIT/TERM ALIAS */ 
000004 IGC001G, /* 456 RESTORE(SVC17) */ 
000005 ICHRFCOO, /* RACF IMS/CICS */ 
000006 ICHRFROO) /* RACF IMS/CICS */ 
000007 INCLUDE LIBRARY(SYS1.SVCLIB) MODULES(IGC09302) 


Ss ialalahetolodedodeleholebeieieieelodolododoholodohiieieieioolodl =10% 11011 11 ©) ih BY-\' Weieieieeledodoioioioieieieieieiedoioioieieieieisieieleleieioieioiaieia 





Figure 17-7 The IEAFIX parmlib member 


17.4.3 Modified link pack area (MLPA) 


This area may be used to contain reenterable routines from APF-authorized libraries that 
are to be part of the pageable extension to the link pack area during the current IPL. The 
MLPA exists only for the duration of an IPL. Therefore, if an MLPA is desired, the 
modules in the MLPA must be specified for each IPL (including quick start and warm 
start IPLs). When the system searches for a routine, the MLPA is searched before the 
PLPA. The MLPA can be used at IPL time to temporarily modify or update the PLPA 
with new or replacement modules. 


17.5 SYS1.PROCLIB 


SYS1.PROCLIB is a library that participates both in system initialization and in normal 
operations. 


17.5.1 The Master Scheduler 


The master scheduler subsystem is used to establish communication between the 
operating system and the primary job entry subsystem, which can be JES2 or JES3. 
When you start z/OS, master initialization routines initialize system services, such as the 
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system log and communication task, and start the master scheduler address space, which 
becomes address space number one (ASID=1). 


Then, the master scheduler may start the job entry subsystem (JES2 or JES3). JES is the 
primary job entry subsystem. On many production systems JES is not started 
immediately, the automation package starts all the tasks in a controlled sequence. Then 
other defined subsystems are started. All subsystems are defined in the parmlib library, 
member IEFSSNxx. These subsystems are secondary subsystems. 


An initial MSTJCLOO load module can be found in SYS1.LINKLIB library. If 
modifications are required, the recommended procedure is to create a MSTJCLxx 
parmlib member. The suffix is specified by the MSTRJCL parameter in the IEASYSxx 
parmlib member. The MSTJCLxx member is commonly called master JCL. It contains 
data definition (DD) statements for all system input and output datasets that are needed to 
do the communication between the operating system and the primary job entry 
subsystem. 


The following is an example of MSTJCLxx parmlib member: 


Example 17-3 Sample master JCL 


//MSTJCLO5 JOB MSGLEVEL=(1,1),TIME=1440 
//EXEC PGM=IEEMB860 

//STCINRDR DD SYSOUT=(A, INTRDR) 
//TSOINRDR DD SYSOUT=(A, INTRDR) 
//1EFPDSI DD DSN=SYS1.PROCLIB,DISP=SHR 
//TEFPARM DD DSN=SYS1.PARMLIB,DISP=SHR 
//SYSUADS DD DSN=SYS1.UADS ,DISP=SHR 
//SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR 


When the master scheduler has to process the start of a started task, the system 
determines whether the START command refers to a procedure or a job. If the IEFJOBS 
DD exists in the MSTJCLxx member, the system searches the JIEFJOBS DD 
concatenation for the member requested in the START command. If there is no member 
by that name in the IEFJOBS concatenation, or if the IEFJOBS concatenation does not 
exist, the system searches the IEFPDSI DD for the member requested in the START 
command. If a member is found, the system examines the first record for a valid JOB 
statement and, if one exists, uses the member as the JCL source for the started task. If the 
member does not have a valid JOB statement in its first record, the system assumes that 
the source JCL is a procedure and creates JCL to invoke the procedure. After JCL source 
has been created (or found), the system processes the JCL. 
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As shipped, MSTJCL00 contains an IEFPDSI DD statement that defines the dataset that 
contains procedure source JCL for started tasks. Normally this dataset is 
SYS1.PROCLIB; it may be a concatenation. For useful work to be performed, 
SYS1.PROCLIB must at least contain the procedure for the primary JES. Let’s see in 
next section. 


17.5.2 A job’s procedure library 


SYS1.PROCLIB contains the JES2 cataloged procedure. This procedure defines the 
job-related procedure libraries. Next figure is an example of defining procedure libraries. 


Example 17-4 How to specify procedure libraries in the JES2 procedure 


//PROCOO DD DSN=SYS1.PROCLIB,DISP=SHR 
// DD DSN=SYS3.PROD.PROCLIB,DISP=SHR 
//PROCO1 DD DSN=SYS1.PROC2,DISP=SHR 


//PROCNN DD DSN=SYS1.LASTPROC,DISP=SHR 


Many installations have very long lists of procedure libraries in the JES procedure. This 
is because JCLLIB is a relatively recent innovation. Care should be taken as to the 
number of users who can delete these libraries as JES will not start if one is missing. 
Normally a library that is in use cannot be deleted but JES does not hold these libraries 
although it uses them all the time. 


Programmers can override the default specification by specifying a /*JOBPARM 
PROCLIB= statement; then, in the name of the procedure library, they must code the name 
of the DD statement in the JES2 procedure that points to the library they want to use. For 
example, you run a job in class A. That class has a default PROCLIB of 
SYS1.PROCLIB. If you want to use a procedure that resides in SYS1.LASTPROC, 
you’ ll need to include a /*JOBPARM PROCLIB=PROCnn in the JCL (see above). 


There is another way to specify a procedure library that is to use the JCLLIB JCL 
statement. 


The JCLLIB statement allows you to code and use procedures without to use system 
procedure libraries. The system searches the libraries in the order in which you specify 
them on the JCLLIB statement, prior to searching any unspecified default system 
procedure libraries. 


Following is an example of the use of the JCLLIB statement. 


Example 17-5 Example of the JCLLIB statement 


//MYJOB JOB 
//MYLIBS JCLLIB 


ORDER=(MY.PROCLIB.JCL,SECOND.PROCLIB.JCL) 
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//S1 EXEC PROC=MYPROC1 


Assuming that the system default procedure library includes SYS1.PROCLIB only, the 
system searches the libraries for procedure MYPROC1 in the following order: 


1. MY.PROCLIB.JCL 
2. SECOND.PROCLIB.JCL 
3. SYS1.PROCLIB 


17.6 System symbols 


System symbols are elements that allow different z/OS systems to share parmlib 
definitions while retaining unique values in those definitions. System symbols act like 
variables in a program; they can take on different values, based on the input to the 
program. When you specify a system symbol in a shared parmlib definition, the system 
symbol acts as a “place holder”. Each system that shares the definition replaces the 
system symbol with a unique value during initialization. 


Each system symbol has a name (begins with an ampersand and optionally ends with a 
period) and a substitution text which is the character string that the system substitutes for 
a symbol each time it appears. 


There are two types of system symbols: dynamic whose substitution text can change at 
any point in an IPL, and static whose substitution text is defined at system initialization 
and remains fixed for the life of an IPL. There are symbols which are reserved for system 
use. 


IEASYMxx parmlib member provides a single place to specify system parameters for 
each system in a multisystem environment. IEASYMxx contains statements that do both 
define static system symbols and specify IEASYSxx parmlib members that contain 
system parameters (SYSPARM statement). 


Look at the following example of a IEASYMxx parmlib member: 


Example 17-6 IEASYMxx parmlib member 


SYSDEF HWNAME(SCZP801) 

LPARNAME (A08) 

SYSNAME (SCO4) 

SYSPARM(R3, 04) 

SYMDEF (&CPCNAME='P801') 

SYMDEF (&DFHSMHST=!ON') 

SYMDEF (&SYSR2=° ZXYSY2?) 

SYMDEF (&SYSR3=?&SYSR1(1:5) .3”) 
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&SYSNAME is replaced by the value of the name of the current system, so this one 
statement works for all the systems in the sysplex. &SYSR2 is used to define the name 
second system residence volume and &SYSR3 is a third. As can be seen the variables can 
be used to construct one another. &SYSR1 is system defined as the first system residence 
volume. 


System symbols are used in cases where multiple z/OS systems will share a single 
parmlib. Here the use of symbols allows individual members to be used with symbolic 
substitution, as opposed to having each system require a unique member. The LOADxx 
parmlib member specifies the IEASYMxx member that the system is to use. 


17.7 Summary 


The role of the system programmer is to install, customize, and maintain the operating 
system. 


As a2Z/OS system programmer, one person must be aware of the following areas: 


z/OS operational system administration 
Workload Management 

System performance 

Job flow 

1/O device management 

Security 

Integrity 

Availability 

z/OS Operation 


vvvvvvvvy 


In order to maximize the retrieving modules performance, the z/OS operating system has 
been designed to maintain in memory those modules that are needed for fast response to 
the operating system as well as for the critical applications. Link pack area (LPA), 
LNKLST, and authorized libraries are the cornerstone of the fetching process. 


17.8 Key terms 








Key terms in this chapter 


HCD IODF SYSRES 
SMP/E LNKLST Linklist 
LLA VLF PARMLIB 
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PROCLIB System Symbols LPA 
FLPA MLPA PLPA 








17.9 Discussion questions 


1, 


Class discussion: mainframe is considered secure because doesn’t permit the “plug 
in” devices and only defined devices by the system programmer can be connected and 
used. In your opinion is this correct? 


Question: look at the following system specifications, and indicate what will be the 
final LNKLST concatenation. 


IEASYSxx: ...,LNK=(00,02,03,05) 

LNKLSTOO: SYS1.CMDLIB,SYS1.BTAMLIB 

LNKLSTO2: SYS1.LINKLIB,LUISM.MYLIB(DSD001) ,SYS2.MIRLIB 
LNKLSTO3: SYS1.AUXLIB,SYS1.JES3 

LNKLSTO5: SYS1.TESTO1, SYS1.TESTLIB 


What happen with the SYS1.LINKLIB specification in LNKLST02? 


Question: Take Example 17-4 on page 17-24 and suppose that the class assigned to a 
certain job has a default PROCLIB concatenation of PROCO0. The job needs a 
procedure that resides in SYS1.OTHERPRO. What can be done to accomplish this? 
Which procedure libraries would be searched if nothing was done ? 

Class discussion: compare the scope of system parametrization for the “program 
search order” in other operating system 


17.10 Exercises 


1. 


Laboratory: find out which IEASYSxx members have been used in the current IPL. 
Did the operator specify the suffix of an alternate IEASYSxx?. 


Laboratory: Did the operator specify any parameter in response to the message of 
SPECIFY SYSTEM PARAMETERS’. If the answer is Y, find the related parmlib 
member(s) for that parameter and obtain the parameter value that would be active if 
that operator response hadn’t occurred. 

Paper: besides the LOADxx parmlib member and the SYSP parameter in the 
response to the system message, there is another place to specify the suffixes of 
IEASYSxx members that the system is to use; this is the IEASYMxx parmlib 
member. Redo Table 17-1 on page Chapter 17.-18 including one column with 
IEASYMxx and considering (05,06) values for the suffixes specified in it. Write 
which are the resultant IEASYSxx concatenations. 
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17.11 Instructor notes 


17.11.1 Answers to Questions and exercises 


Re 17.11 Q2 
As a result of these specifications, the following datasets, in the order specified, 
are concatenated to SYS1.LINKLIB (after SYS1.MIGLIB and SYS1.CSSLIB): 
SYS1.CMDLIB, SYS1.BTAMLIB, LUISM.MYLIB, SYS2.MIRLIB, 
SYS1.AUXLIB, SYS1.JES3, SYS1.TESTO1 and SYS1.TESTLIB. 


The specification of SYS1.LINKLIB is ignored 


Re 17.11 Q3 


Because there is no DD statement in the JES2 procedure that points to the library we 
need, we may use the JCLLIB JCL statement. We’d write a DD statement like the 
following: 


//MYLIBS JCLLIB ORDER=(SYS1.0THERPRO) 


SYS1.PROCLIB and SYS3.PROD.PROCLIB would be searched if nothing was added. 


Re 17.13 Q1 
Display using D IPLINFO command 


Re 17.13 Q2 
Look at the display resulting from the D IPLINFO command. If (OP) appears on the 
IEASYS line then the operator entered values 


Re 17.13 Q3 


Specifying the suffixes in IEASYMxx is the same as in LOADxx because the system 
concatenates the members in the operator does not specify the suffixes at IPL. If the 
operator specifies the suffixes, these override suffixes in IEASYMxx or LOADxx. 
Therefore, the third and fourth resultant concatenations remain the same. The first now is 
(00, 05, 06) andthe second (00, 01, 02, 05, 06). 


17.11.2 re 17.4.2 Linklist - old method 


17-28 


This section describes the old method of specifying the linklist. This method has been 
replaced in most installations by the use of the PROGxx member. The LNKLSTxx 
member of parmlib can be used to specify the program libraries that are to be 
concatenated to SYS1.LINKLIB. The system automatically concatenates the other two 
datasets. IEASYS00 (and IEASYSaa, IEASYSbb, ...) parmlib member is the most likely 
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place to put installation parameters. The LNKLSTxx member is selected through the 
LNK parameter in the IEASYSxx member of the SYS1.PARMLIB. 


Following is an example of specification of the LNKLST member(s) to use. 


Example 17-7 IEASYSxx specification for LNKLST concatenation 
LNK=(00,01,02) 


An example of overriding the value of the LNK parameter in the IEASYSxx during 
system initialization is as follows: 


Example 17-8 Overriding the LNKLST concatenation through operator intervention 


IEA101A SPECIFY SYSTEM PARAMETERS FOR z/OS 02.05.00 HBB6605 
R 00,LNK=03 
TEE600I REPLY TO 00 IS;LNK=03 


Instead of using the concatenation of the three different LNKLSTxx members, only 
LNKLST03 will be used. 


No default member is provided for LNKLSTxx, but following is the sample LNKLSTxx 
member that may be found in SYS1.SAMPLIB. 


Example 17-9 Sample LNKLSTxx member 


SYS1.LINKLIB, Always 1st LNKLST dataset (parmlib specification ignored) 
SYS1.MIGLIB, Always 2nd LNKLST dataset (parmlib specification ignored) 
SYS1.CSSLIB, Always 3rd LNKLST dataset (parmlib specification ignored) 
SYS1.CMDLIB Needed in linklist in order to run TSO/E 


17.11.3 Additional parameters in LOADxx 


Some additional parameters in LOADxx that were not described in the student text: 


> The NUCLSTxx member that you use to add and delete modules from the nucleus 
region at IPL time. This member must reside in the same data set as the LOADxx 
member. NUCLST statement is used. 

> An alternate nucleus ID (NUCLEUS statement). You may want to cause the IPL 
program to read a member of a nucleus dataset that is different to IEANUCO01. One 
reason for such a nucleus switch may be the need to apply a PTF to the nucleus. There 
is an alternative way of specifying a secondary nucleus for IPL which is modifying 
the alternate nucleus character of the LOAD parameter string in the system control 
(STSCTL) frame of the system console. If none of the above are specified, the system 
loads the standard (or primary) nucleus IEANUC01). 
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17.11.4 Overview of IEASYSxx parameters 


The following list briefly defines the most important system parameters that can be 
placed in an IEASYSxx member. There are many parameters which function is to 
complete the name of other parmlib members where the parameters reside. 


Parameter 
APF 


CLOCK 


CLPA 
CMD 


CON 


CSA 


CVIO 


FIX 


LNK 


LOGREC 
LPA 


MAXUSER 


MLPA 
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Use of the parameter 

Names the parmlib member (IEAAPFxx) that contains 
authorized library names. 

Completes the name of the parmlib member (CLOCKxx) that 
prompts the operator to initialize the TOD clock during the 
system initialization, and specify the difference between the 
local time and Greenwich Mean Time (GMT). 

It denotes that the IPL is cold start. 

Completes the name of the COMMNDxx parmlib member that 
contains commands to be issued internally during master 
scheduler initialization. 

Completes the name of the parmlib member (CONSOLxx) that 
centralizes control of the console configuration for your 
installation. 

Specifies the sizes of the virtual common service area and 
extended common service area. 

It denotes that the IPL is quick start. 

Completes the name of one or more parmlib members 
(IEAFIXxx) that contains names of modules that are to be 
placed in a fixed LPA that lasts for the duration of the IPL 
Completes the name of one or more parmlib members 
(LNKLSTxx) that contain names of data sets that are to be 
concatenated to SYS1.LINKLIB to form the LNKLSTxx 
concatenation. You can also use PROG parameter to specify the 
PROGxx member that defines the LNKLST concatenation 
(among other things). 

Specifies the logrec recording medium for error processing. 
Completes the name of one or more parmlib members 
(LPALSTxx) that contains names of data sets that are to be 
concatenated to SYS1.LPALIB for building the pageable LPA 
(PLPA and extended PLPA). 

Specifies a value that the system uses (along with others) to 
limit the number of jobs and started task that the system can run 
concurrently during a given IPL. 

Completes the name of one or more parmlib members 
(IEALPAxx) that names modules that are to be places in a 
modified LPA that lasts for the duration of the IPL. 
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MSTRJCL Complete the name of the MSTJCLxx data set that contains the 
JCL used to start the master scheduler address space. 
OMVS Specifies the parmlib member or members (BPXPRMxx) to use 


to locate the parmlib statements to configure the UNIX System 
Services kernel. 


PAGE Gives the names of new page data sets to be used as additions to 
or replacements for existing page sets. 
PROG Completes the name of one or more parmlib members 


(PROGxx) that specify the format and contents of the 
APF-authorized library list. You can also use PROG instead of 
LNKLSTxx to define the LNKLSTxx concatenation and 
activate it at IPL. 


SMF Specifies a parmlib member (SMFPRMxx) from which SMF 
will obtain its parameters. 

SMS Specifies a parmlib member (IGDSMSxx) from which SMS 
will obtain its parameters. 

SSN Completes the name of the parmlib member IEFSSNxx, which 


contains the information to be used in identifying subsystems 
that are to be initialized. 


SYSNAME Specifies the name of the system being initialized. 

SYSP Specifies one or more alternate system parameter lists 
(IEASYSxx) that are to be read by the initialization program in 
addition to IEASYS00. 

VAL Names one of more parmlib members (VATLSTxx) that 


contains mount and use attributes of direct access devices. 


17.11.5 NUCLSTxx 


The NUCLSTxx member allows you to load installation-supplied modules into the 
system’s region at IPL-time. This is a specialist area and the majority of systems are 
moving away from modifications of this type. 


You can use NUCLSTxx to: 


> Add your installation’s modules to the nucleus region. 
> Delete nucleus-resident modules and replace them with alternate versions of the 
modules. 


NUCLSTxx saves you from having to link-edit your installation’s nucleus-resident 
routines into the IEANUCO0x member of SYS1.NUCLEUS; this is a required partitioned 
data set that contains the resident portion of the control program, and also the nucleus 
initialization program (NIP), and programs for hardware configuration definition (HCD) 
used by IPL.This system data set must reside on the system residence volume. 


Chapter 17. System libraries and system programming 17-31 


Chapter17 system programming tasks.fm Draft Document for Review December 3, 2004 3:15 pm 


The modules to be added to the nucleus region, or deleted from it, must reside in 
members of SYS1.NUCLEUS. To add or delete modules, simply specify the members on 
INCLUDE or EXCLUDE statements in NUCLSTxx. 


As we mentioned above, the NUCLSTxx member must reside in the same dataset as the 
LOADxx member and you have to code a NUCLST statement to specify the NUCLSTxx 
member to be used. 


17.12 Demonstration 


17-32 


In 9.16.3, “Demonstrations” on page 9-21, students compiled and executed some 
programs. We can now demonstrate a method of productionizing these programs. In this 
case we are going to take the load library in which these programs exist and add it to the 
linklist. Other methods might include adding the programs to an exisiting library or 
possibly using a steplib to a production library in every job. The are advantages and 
disadvantages to each method. Adding it to the linklist means that these programs are 
available to just about everyone on the system and this might not be what is wanted. 


1. Select the library to be added to the linklist. Both the data set name and the volume 
serial number will be needed. 

2. Issue the commands to be found in ZPROF.ZSCHOLAR.LANG.CNTL(LLAACT) 
replacing the data as required. Each time a new linklist is created the name must be 
unique during that IPL. 


3. Run the various programs. The jobs in ZPROF.ZSCHOLAR.LANG.CNTL(LLA*), 
i.e. the members beginning LLA, will run the various programs without a steplib. 


4. Use the commands in ZPROF.ZSCHOLAR.LANG.CNTL(LLADEL) to remove the 
library from the linklist when all the jobs have completed successfully. If there is time 
try running one of the jobs again to show that it will now fail as it will be unable to 
find the program. 
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18 


Security on 2/OS 








Objective: 


In this chapter, you will learn about: 


Security concepts 

RACF and its interface with the operating system 
System authorization facility (SAF) overview 
RACF administration 

Integrity concepts 

Authorization of programs 
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An installation’s data and application programs are among its most valuable resources, 
and must be protected from unauthorized access both internally (employees) and 
externally (customers, business partners, and hackers). 


Over time, it has become much easier to create and access computerized information. No 
longer is system access limited to a handful of highly skilled programmers. Information 
can now be created and accessed by almost anyone who takes a little time to become 
familiar with the newer, easier-to-use, high-level inquiry languages. As a result of this 
improved ease of use, the number of people using computer systems has increased 
dramatically. 


More and more people are becoming increasingly dependent on computer systems and 
the information they store in these systems. As the general computer literacy and the 
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number of people using computers has increased, the need for data security has taken on 
a new level of importance. No longer can the installation depend on keeping data secure 
simply because no one knows how to access the data. 


Further, making data secure does not mean just making confidential information 
inaccessible to those who should not see it. It means preventing the inadvertent 
destruction of files by people who may not even know that they are improperly 
manipulating data. 


An operating system is said to have system integrity when it is designed, implemented 
and maintained to protect itself against unauthorized access, and does so to the extent that 
security controls specified for that system cannot be compromised. Specifically for z/OS, 
this means that there must be no way for any unauthorized program, using any system 
interface, defined or undefined: 


> To obtain control in an authorized state 
> To bypass store or fetch protection 
> To bypass password checking 


In this chapter, we cover the facilities of z/OS that provide its high level of security and 
integrity. 


18.1 Why security? 
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Most companies now hold much of their data on computer systems. These are now 
essential resources critical to the success of the company. It is therefore essential that 
access to this data is carefully controlled and that appropriate access is granted. If 
everyone was given the same access then a clerk in the warehouse could delete a 
salesman’s contracts losing the company money. Big companies are very wary about 
admitting to incidents of hacking (breaching security), as this would lead to loss of 
confidence and a reduced stock price. 


Of course data about customers is a valuable resource that could be sold to competitors; 
or the threat of a sale could lead to blackmail. So the aim of any security policy is to 
provide users with only their required level of access and to deny non-authorized users 
access. This is one reason auditors prefer that users or groups are granted specific access 
rather than using the universal access facilities. The traditional focus of mainframe 
security was to focus on stopping unauthorized people logging on to the system and then 
ensuring that users were only allowed access to data on a need to know basis. As 
mainframes have become Internet servers, additional security has been required. There 
are outside threats such as hackers, viruses, and trojan horses; the security server includes 
tools to deal with these. 


However the main threat to company data has always been from within. An employee 
within a company has a much better chance of obtaining data than someone outside and a 
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well- thought-out security policy is always the first line of defense. In addition to that, 
z/OS provides a number of integrity features to minimize intentional or accidental 
damage from other programs. This chapter covers a few of these. 


18.2 Security roles 


There are different functions that normally are provided by different individuals. Usually, 
the system programmer, working with management, decides the overall security policy 
and procedures. There is also an administrative or clerical function that implements the 
security policies. 


The system administrator assigns user IDs and initial passwords, and ensures that the 
passwords are non-trivial, random, and frequently changed. Because the user IDs and 
passwords are so critically important, special care must be made to protect the files that 
contain them. 


There may even be a separate security manager who sets the policies. If so, the system 
programmer may not have direct responsibility for security, other than advising the 
security manager about new products. 


These duties should be done by different individuals to provide the required separation of 
duties necessary to prevent any one individual from having uncontrolled access to the 
system. 


Many installations run several copies of z/OS and often do not permit general TSO/ISPF 
users to access the production systems. z/OS security controls can protect the production 
environment if they are properly configured. Even with proper security controls a 
TSO/ISPF user (either maliciously or accidentally) can impact important production 
work. 


18.3 z/OS Security Server 


An installation uses facilities inherent in z/OS and provided by other program products to 
provide this security. This package is called the IBM Security Server, but it is commonly 
referred to by the name of its most well-known component, RACF. z/OS security 
provisions include: 


> Controlling the access of users (user ID and password) to the system 


> Restricting the functions that an authorized user can perform on the systems’ data 
files and programs 
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For 


those students who would like to learn more about the tools available to a z/OS 


security administrator, here is a list of the security components of z/OS that are 
collectively known as the Security Server. 


> 


DCE Security Server provides a fully functional OSF DCE 1.1 level security server 
that runs on z/OS. 


Lightweight Directory Access Protocol (LDAP) Server is based on a client/server 
model that provides client access to an LDAP server. An LDAP directory provides an 
easy way to maintain directory information in a central location for storage, update, 
retrieval, and exchange. 


z/OS Firewall Technologies is an IPV4 network security firewall program for z/OS. 
In essence, the z/OS firewall consists of traditional firewall functions as well as 
support for virtual private network. 


The inclusion of a firewall means that the mainframe can be connected directly to the 
Internet if required without any intervening hardware and can provide the required 
levels of security to protect vital company data. With the VPN technology, securely 
encrypted tunnels can be established through the Internet from a client to the 
mainframe. 


Network Authentication Service for z/OS provides Kerberos security services 
without requiring that you purchase or use a middleware product such as Distributed 
Computing Environment (DCE). 


Enterprise Identity Mapping (EIM) offers a new approach to enable inexpensive 
solutions to easily manage multiple user registries and user identities in an enterprise. 


PKI Services allows you to establish a Public key infrastructure and serve as a 
certificate authority for your internal and external users, issuing and administering 
digital certificates in accordance with your own organization’s policies. 


Resource Access Control Facility (RACEF) is the primary component of the z/OS 
Security Server and works closely with z/OS to protect its vital resources. 


The topic of security can be a whole course by itself. In this textbook, we introduce you 
to the RACF component and show how its features are used to implement z/OS security. 


18.4 RACF 


Access, in a computer-based environment, means the ability to do something with a 
computer resource (for example, use, change, or view something). Access control is the 
way by which this ability is explicitly enabled or restricted. Computer-based access 
controls are called logical access controls. These are protection mechanisms that limit 
users’ access to information to only what is appropriate for them. 
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Logical access controls are often built into the operating system, or may be part of the 
logic of applications programs or major utilities, such as database management systems. 
They may also be implemented in add-on security packages that are installed into an 
operating system; such packages are available for a variety of systems, including PCs and 
mainframes. Additionally, logical access controls may be present in specialized 
components that regulate communications between computers and networks. 


The Resource Access Control Facility (RACF) is an add-on software product that 
provides the basic security to a mainframe system. There are other security software 
packages available. Examples are ACF2 or Top Secret, both from Computer Associates. 


RACF protects resources by granting access only to authorized users of the protected 
resources. RACF retains information about the users, resources, and access authorities in 
special structures called profiles on its database and refers to the profiles when deciding 
which users should be permitted access to protected system resources. 


To accomplish its goals, RACF gives you the ability to: 


Identify and authenticate users 

Authorize users to access the protected resources 

Log and report various attempts of unauthorized access to protected resources 
Control the means of access to resources 

Allow applications to use the RACF macros 
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Figure 18-1 on page 18-6 shows a simple view of RACF functions. 


Chapter 18. Security on z/OS 18-5 


Chapter18 security.fm Draft Document for Review December 3, 2004 3:15 pm 









Security 
administration 




















Audit and 

Integrity 

reports 

Violation 
User identification alerts 
and authorization 








Resource 
authorization 
checking 
and system 
control 

















Figure 18-1 RACF functions overview 


RACF controls access to and protects resources. For a software access control 
mechanism to work effectively, it must first identify the person who is trying to gain 
access to the system, and then verify that the user is really that person. 


RACF uses a user ID and a system-encrypted password to perform its user identification 
and verification. The user ID identifies the person to the system as a RACF user. The 
password verifies the user's identity. Often exits are used to enforce a password policy 
with a minimum length, lack of repeating characters or adjacent keyboard letters, and 
also the use of numerics as well as letters. Popular words such as “password” or the use 
of the user ID are often banned. The other important policy is the frequency of password 
change. If a user ID has not been used for a long time, it may be revoked and special 
action is needed to use it again. When someone leaves a company, there should be a 
special procedure that ensures that the user IDs are deleted from the system. 


18.4.1 Protection levels 
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The security administrator can grant access of a resource to a user on one of five 
hierarchical levels. Each level includes the privileges of the one below it (not counting 
“NONE”). 
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ALLOC 
CONTROL 
WRITE 
READ 
NONE 
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NONE allows no access. If WRITE is granted, then READ is implied. CONTROL is 
most often used with VSAM data sets where it permits a reorganization but not a delete. 


ALLOC allows creation and deletion of data sets. 


Here are the system elements that RACF is designed to protect. 


18.4.2 Protecting data sets 


To protect a data set, RACF builds a data set profile and stores it in the RACF database. 
You can protect tape data sets and the following types of DASD data sets: 


VSAM data sets 


Generation data group (GDG) data sets 


vvvvy 


supplied prefix 


18.4.3 Protecting general resources 


Cataloged and uncataloged non-VSAM data sets 


Data sets that have the same name but reside on different volumes 


Data sets and catalogs with single-level names obtained through an installation 


Just as you can protect a data set, you can define the general resources you want to 


protect with RACF. These include: 


> Volumes 
— DASD 
— Tape 
> Load modules (programs) 
— IMS 
¢ Transactions 
¢ Transaction groups 
¢ Application groups 
— TSO 
¢ Logon procedures 
« Account numbers 
¢ User attributes 
¢ Performance groups 
— CICS (transactions and other elements) 
— DFSMS 
« Management class 
* Storage class 
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> Applications and middleware (such as DB2) 
> Terminals 
> Installation-defined resources 


18.4.4 RACF and the operating system 


To visualize how RACF works, picture RACF as a layer in the operating system that 
verifies users' identities and grants user requests to access resources. 


Assume, for example, that you have been identified and verified to the RACF-protected 
system and now want to modify an existing RACF-protected resource. After you enter a 
command to the system to access the resource, a system resource manager (such as data 
management) processes the request. The resource manager, based on what RACF 
indicates, either grants or denies the request. Note that it is not RACF that allows or 
denies access but the resource manager interpreting the return codes from RACF. 


Figure 18-2 shows how RACF interacts with the operating system to allow access to a 
protected resource. In a similar manner, the operating system interacts with RACF to 
identify and verify users. 
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Figure 18-2 Operating system and RACF 


1. A user requests access to a resource using a resource manager (for example, TSO/E). 


2. The resource manager issues a RACF request to see if the user can access the 
resource. 


RACF refers to the RACF database or in-storage data and... 
..checks the appropriate resource profile. 


Based on the information in the profile... 


Nn PY 


RACF passes the status of the request to the resource manager. 
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7. The resource manager grants (or denies) the request. 


18.4.5 RACF and System Authorization Facility (SAF) 


The system authorization facility (SAF) is part of the z/OS operating system and 
provides the interfaces to the callable services provided to perform authentication, 
authorization, and logging. See Figure 18-3. 


SAF does not require any other product as a prerequisite, but overall system security 
functions are greatly enhanced and complemented if it is used concurrently with RACF. 
The key element in SAF is the SAF router. The SAF router is always present, even when 
RACF is not present. 


The SAF router provides a common focal point for all products providing resource 
control. This focal point encourages the use of common control functions shared across 
products and across systems. The resource managing components and subsystems call 
the z/OS router as part of certain decision-making functions in their processing, such as 
access-control checking and authorization-related checking. These functions are called 
control points. 
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Figure 18-3 Concepts of RACF profile checking 





As Figure 18-3 on page 18-9 shows, the system authorization facility (SAF) 
conditionally directs control to RACF, if RACF is present, or to a user-supplied 
processing routine, or both, when receiving a request from a resource manager. 
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18.4.6 RACF structure 
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RACF enables the organization to define individuals and groups who use the system 
RACF protects. For example, for a secretary in the organization, a security administrator 
uses RACF to define a user profile that defines the secretary’s user ID, initial password, 
and other information. 


A group is a collection of individuals who have common needs and requirements. For 
example, the secretaries for a whole department may be defined as one group. 


RACF also enables an installation to define what authorities one user has, or what 
authorities a group to which the user belong has. RACF controls what the user can do on 
the system. Some individuals have a great degree of authority, while others have little 
authority. The degree of authority users are given is based on what they need to do their 
job. 


Besides defining user and group authorities, RACF protects resources. A resource is the 
organization’s information stored in its computer system, such as data sets. For example, 
a secretary might have a data set as a resource. RACF provides a way to control who has 
authority to access a resource. 


RACF stores all this information about users, groups, and resources in profiles. A profile 
is a record of RACF information that has been defined by the security administrator. 
There are user, group, and resource profiles, as Figure 18-4 on page 18-11 shows. 
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Figure 18-4 RACF structure overview 














Using information in its profiles, RACF authorizes access to certain resources. RACF 
applies user attributes, group authorities, and resource authorities to control use of the 
system. 


> The user profile provides the user attributes. User attributes describe what 
system-wide and group-wide access privileges a user have to protected resources. 

> The group profile describes the kind of authority a user as a group member have to 
access resources that belong to its group. 

> The resources themselves have profiles describing the type of authority needed to use 
them. 


The security administrator or someone in authority in the organization controls the 
information in the user profiles, in group profiles, and in resource profiles. 


A resource profile can contain an access list as well as a default level of access authority 
for the resources it protects. An access list identifies the access authorities of specific 
users and groups, while the default level of access authority applies to anyone not 
specifically in the access list. 
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RACF recognizes resource classes as those resources that are similar to each other. A 
tape volume, regardless of its contents or physical location, represents, for example, a 
specific way of storing data; tape volumes are a resource class. As another example, 
terminals might have different physical attributes, but they all perform similar 
input/output functions; terminals are a resource class. 


When you define a resource class, RACF places control information for the new resource 
class into a class descriptor table. The control information includes: 


> The resource class name 
> The syntax rules for the resource names within the class 
> The location of the auditing and statistics flags for the class 


The security administrator maintains the RACF system options according the security 
objectives and policies. Some examples of system-wide settings are: 


Establishing Password Syntax Rules 

Setting the Maximum Password Change Interval 
Extending Password and User ID Processing 
Revoking Unused User IDs 

Activating List-of-Groups Checking 

Setting the RVARY Passwords 

Restricting the Creation of General Resource Profiles 
Activating General Resource Classes 


vvvvvvvyy 


18.5 RACE functions 


For a refresher on RACF functions, refer back to Figure 18-1 on page 18-6. To 
accomplish its goals, RACF gives you the ability to: 


Identify and authenticate users 

Authorize users to access the protected resources 

Log and report various attempts of unauthorized access to protected resources 
Control the means of access to resources 
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18.5.1 User identification and authorization checking 


18-12 


RACF identifies you when you log on to the operating system you want to use. It does so 
by requiring a user identification, the user ID—a unique identification string. RACF then 
verifies that you are the user you say you are by requesting and checking a password. 
Each RACF user ID has a unique password. The password is one-way encrypted so no 
one can learn your password, not even an administrator. A user ID will be revoked after a 
set number of invalid password attempts and an administrator will have to reset the 
userid and generally set a new password, which must be changed on first use. 
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During authorization checking, RACF checks the resource profile to ensure that the 
resource can be accessed in the way requested and that you have the proper authorization 
to access the resource. The necessary user-resource requirements must match before 
RACF grants the access request to a protected resource. 


When a user requests access to a resource that has a security classification, RACF 
performs two checks. 


1. 


RACF compares the security level in the user and resource profiles. If the resource 
has a higher security level than the user, RACF denies the request. 


RACF compares the list of categories in the user's profile with the list of categories in 
the resource profile. These include installation-defined names corresponding to 
departments or areas within an organization. If the resource profile contains a 
category that is not in the user's profile, RACF denies the request. 


If the security comparison allows access to the RACF-protected resource, you can permit 
or deny access in either of two ways: 


> 


Explicitly, by assigning each user or group a specific access authority to the resource, 
or 


Implicitly, with a universal access authority (UACC). All users or groups of users in 
the system who are not specifically named in a list of authorized users for a resource 
can still access the resource with the authority specified by the UACC. The UACC 
also applies to users not defined to RACF. 


Figure 18-5 on page 18-14 illustrates a conceptual model of how RACF checks profiles 
to ensure who (in a user profile) is accessing what and how (in a resource profile). 
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Figure 18-5 RACF profile checking 


The boxes refer to the installation-assigned attributes and authorities for users and 
resources that determine which users can access which resources in what manner. 


> A request for a resource is granted if all the requisites in the “boxes” are satisfied. 
> A request for a resource is denied if one requisite is not satisfied. 


18.5.2 Logging and reporting 


RACF maintains statistical information, such as the date, time, and number of times that 
a user enters a system and the number of times a specific resource was accessed by any 
one user. RACF also writes security log records when it detects: 


> Unauthorized attempts to enter the system 
> Authorized or unauthorized attempts to access RACF-protected resources 
> Authorized or unauthorized attempts to enter RACF commands 


18.5.3 Security administration 


Data security is the protection of data from accidental or deliberate unauthorized 
disclosure, modification, or destruction. Based on this definition, it is apparent that all 
data-processing installations have at least potential security or control problems. Users 
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have found, from past experience, that data security measures can have a significant 
impact on operations in terms of both administrative tasks and demands made on the end 
user. 


RACF gives the user defined with the SPECIAL attribute (the security administrator) 
many responsibilities both at the system level and at the group level. The security 
administrator is the focal point for planning security in the installation and needs to: 


Determine which RACF functions to use 
Identify the level of RACF protection 
Identify which data RACF is to protect 
Identify administrative structures and users 
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Determining the RACF functions to use 


RACF provides many functions to help achieve the level of protection needed for an 
installation. Some of the factors that determine what functions to select are: 


> Security objectives 
> The security measures that already exist 
> An evaluation of how RACF can help to reach the goals 


The success key factor is to understand that several RACF functions exist and what 
RACF functions the security administrator will implement. 


Identifying the level of RACF protection 

RACF allows the security administrator to specify different levels of protection for the 
resources and to gradually increase the level of RACF protection. In all cases, RACF can 
be used to report about access to the resources, for example: 


> Allow or deny access to resources, and log and report user access to resources. 

> Issue and log warning messages about user access to resources that would normally 
be denied, but allow access for a limited time. This is called the grace period. 

> Provide full RACF protection to your resources and log and report both successful 
and unsuccessful access attempts. 


Identifying the data to protect 

Every installation has varying amounts of confidential data and varying degrees of 
confidentiality. However, more and more installations are choosing to protect most, if not 
all, of their resources. The problem to be solved by the security administrator is how to 
protect resources in a simple yet effective manner and how to achieve this protection with 
minimum impact on the end user. 


RACF maintains information entries called profiles in the RACF database. It uses them 
to protect DASD and tape data sets and general resources, such as tape volumes and 
terminals. 


Chapter 18. Securityon z/OS 18-15 


Chapter18 security.fm Draft Document for Review December 3, 2004 3:15 pm 


> Data set profiles contain security information about DASD and tape data sets. 
> General resource profiles contain security information about general resources. 


Each RACF-defined resource has a profile, though the security administrator can 
optionally use a single profile to protect multiple resources. 


18.5.4 RACF Remote Sharing Facility (RRSF) 


The RACF remote sharing facility (RRSF) allows you to administer and maintain RACF 
databases that are distributed throughout the enterprise. It provides improvements in 
system performance, system management, system availability, and usability. RRSF helps 
to ensure that data integrity is kept across system or network failures and delays. It lets 
you know when key events have occurred and returns output to view at your 
convenience. 


18.5.5 RACF with middleware 


Major subsystems such as CICS and DB2 use the facilities of RACF to protect 
transactions and files. Much of the work to configure RACF profiles for these 
subsystems is done by the CICS and DB2 system programmers. So there is a need for 
people in the roles to have a good understanding of RACF and how it relates to the 
software they manage. 


18.6 Operator console security 
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We can look at one example of how z/OS security affects system functions by discussing 
the operator consoles. Console security means controlling which commands operators 
can enter on their consoles to monitor and control z/OS. How you define command 
authorities for your consoles or control logon for operators allows you to plan the 
operations security of your z/OS system or sysplex. In a sysplex, because an operator on 
one system can enter commands that affect the processing on another system, your 
security measures become more complicated and you need to plan accordingly. 


If your installation plans to use extended multiple console support (MCS), you should 
consider ways to control what an authorized TSO/E user can do during a console session. 
Because an extended MCS console can be associated with a TSO/E user ID and not a 
physical console, you might want to use RACF to limit not only the z/OS commands a 
user can enter but from which TSO/E terminals the user can enter the commands. 


You can control whether an operator can enter commands from a console: 


> Through the AUTH keyword on the CONSOLE statement of CONSOLxx 
> Through the LOGON keyword of the DEFAULT statement and RACF commands 
and profiles. 
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18.6.1 Controlling command authority with the AUTH attribute 


The AUTH keyword on the CONSOLE statement of CONSOLxx allows you to control 
the command authority of your full-capability consoles so that the system accepts 
commands defined by command group that you assign for the console. For example, 
consoles with master authority need to issue all commands, including those that affect 
other consoles (including extended MCS consoles). On the other hand, a console used 
only to issue I/O commands, such as PURGE, MOUNT, and UNLOAD, needs the 
authority to issue only certain commands. For this reason, z/OS commands are grouped 
into system command groups that allow you to control which commands operators can 
issue from any given console. 


z/OS commands are assigned to one of five command groups according to command 
function. The command groups are: 


Informational commands (INFO) 
System control commands (SYS) 

1/O control commands (IO) 

Console control commands (CONS) 
Master console commands (MASTER) 
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An operator can enter informational commands from any full-capability console. You can 
specify any combination of SYS, IO, and CONS together on the AUTH keyword so that 
an operator can enter these commands (along with informational commands) from the 
console. If an operator enters a command at a console where it is not authorized, z/OS 
rejects the command and sends an error message to the issuing console. 


Authorizing operators and commands 


Note to Reviewer: Need the meaning of SCMCS 


If your installation requires additional security controls on the use of system commands, 
you must first determine what controls are required. For example, do you want to require 
all your operators to logon to MCS or SMCS consoles, or do you want certain operators 
with special authority to be able to enter commands that require a higher authority than 
the console allows? Do you want to audit logon activity? If so, do you want to log all 
command activity or only unauthorized, or unsuccessful, attempts to issue system 
commands? Using RACF and the LOGON keyword in CONSOLxx can help you achieve 
the kind of added security you might need. 


If your installation uses SMCS consoles, IBM strongly recommends that you use RACF 
to prevent an SMCS console from making itself the master console. That is, provide an 
MVS.VARY.MSTCONS profile in the OPERCMDS class and ensure the user does not 
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have READ or greater authority. Note that, if you do not require operator LOGON, it is 
extremely difficult, if not impossible, to control authorization. 


Other ways to control command authority for consoles 

If you do not use RACF to override MCS or SMCS console authority, you can authorize 
specific commands issued from an MCS or SMCS console through the command 
installation exit. You can specify command installation exits in MPFLSTxx. 


18.7 Integrity 


There are many features and facilities in z/OS that were designed specifically to protect 
one program from affecting another one, either intentionally or accidentally. This is why 
z/OS is known for program integrity as well as security. 


This section discusses: 


> The authorized program facility (APF) 
> Storage protection 
> Cross-memory communication 


18.7.1 Authorized programs 
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z/OS contains a feature called the authorized program facility (APF) to allow selected 
programs to access sensitive system functions. APF was designed to avoid integrity 
exposures. The installation identifies what libraries contain those special functions or 
programs. Those libraries are then called APF (authorized program facility) libraries. 


You can use the authorized program facility (APF) to identify system or user programs 
that can use sensitive system functions. For example, APF: 


> Restricts the use of sensitive system supervisor call (SVC) routines (and sensitive 
user SVC routines, if you need them) to APF-authorized programs 

> Allows the system to fetch all modules in an authorized job step task only from 
authorized libraries, to prevent programs from counterfeiting a module in the module 
flow of an authorized job step task 


Many system functions, such as supervisor calls (SVCs) or special paths through SVCs, 
are sensitive. Access to these functions must be restricted to only authorized programs to 
avoid compromising the security and integrity of the system. 


The system considers a task authorized when the executing program has the following 
characteristics: 


> Runs in supervisor state (bit 15 of the program status word (PSW) is zero). For a brief 
look at a PSW, see Appendix G, “Registers and PSW”. 
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> Runs with PSW key 0 to 7 (bits 8 through 11 of the PSW contain a value in the range 
0 to 7). 
> All previous programs executed in the same task were APF programs. 


The authorized program facility allows your installation to identify system or user 
programs that can use sensitive system functions. 


Authorized libraries 

Libraries that contain authorized programs are known as authorized libraries. As 
Figure 18-6 shows, APF-authorized programs must reside in one of the following 
authorized libraries: 


SYS1.LINKLIB 

SYS1.SVCLIB 

SYS1.LPALIB 

Authorized libraries specified by your installation 
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Authorized libraries 





e SYS1.LINKLIB 
e SYS1.LPALIB 
e SYS1.SVCLIB 


iz 






+ 





e List of installation defined 
libraries 














Figure 18-6 Authorized program facility and authorized libraries 
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Note: By default, the libraries in the LNKLST concatenation are considered 
authorized unless you specified LNKAUTH=APFTAB in the IEASYSxx parameter 
list. However, if the system accesses the libraries in the LNKLST concatenation 
through JOBLIB or STEPLIB DD statements, the system does not consider those 
libraries authorized unless you specified the library name in the APF list by using the 
PROGxx parmlib member. If a JCL DD statement concatenates an authorized library 
in any order with an unauthorized library, the entire set of concatenated libraries is 
treated as unauthorized. SYS1.LPALIB is treated as an authorized library only while 
the system builds the pageable link pack area (PLPA) using the LPALSTxx parmlib 
member. All modules in PLPA are marked as coming from an authorized library. 
When accessed through a STEPLIB, JOBLIB, or TASKLIB DD statement, 
SYS1.LPALIB is considered an authorized library only if you have included it in the 
APF list. 


Authorizing a program 

To authorize a program, you must first assign the authorized code to the first load module 
of the program. APF prevents authorized programs from accessing any load module that 
is not in an authorized library. When the system attaches the first load module of a 
program, the system considers the program APF-authorized if the module meets both the 
following criteria: 


1. The module is contained in an authorized library. 


2. The module is link-edited with authorized code, AC=1 (to indicate that you want to 
authorize the job step task). This code is contained in a bit setting in the partitioned 
data set (PDS) directory entry for the module. 


Guidelines for using APF 


When you use APF authorization, you must control which programs are stored in the 
authorized libraries. If the first module in a program sequence is authorized, the system 
assumes that the flow of control to all subsequent modules is known and secure as long 
as these subsequent modules come from authorized libraries. 


To ensure that this assumption is valid you should: 


> Ensure that all programs that run as authorized programs adhere to your installation's 
integrity guidelines. 


> Ensure that no two load modules with the same name exist across the set of 
authorized libraries. Two modules with the same name could lead to accidental or 
deliberate mix-up in module flow, possibly introducing an integrity exposure. 


> Link edit with the authorization code (AC=1) only the first load module in a program 
sequence. Do not use the authorization code for subsequent load modules, thus 
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ensuring that a user cannot call modules out of sequence, or bypass validity checking 
or critical-logic flow. 


Note: It is strongly recommended that you protect the libraries in the APF list with 
generic security product profiles so only selected users can store programs in those 
libraries. 


Authorizing libraries 





e System programs usually: 

> reside in APF-authorized 
libraries 

> execute in supervisor state 

> use storage key 0 to through 7 


e Authorized libraries: 
> SYS1.LINKLIB 
> SYS1.LPALIB 
> SYS1.SVCLIB 
> List of installation 

defined libraries 






e Unauthorized 
libraries. 


e Application programs usually: 
> reside in non-authorized 
libraries 
>» execute in problem state 
> use storage key 8 











Figure 18-7 Authorizing libraries 


The APF list is built during IPL using those libraries specified in the PROGxx parmlib 
members, indicated by the PROG parameter in IEASYSxx, or from the operator's 
console at system initialization. 


Note: You can also dynamically modify the APF list after IPL, but only when you 
have used the dynamic APF format in PROGxx. 


You can use the following ways to update the content of the APF table dynamically: 


>» Use PROGxx parmlib member which includes the appropriate APF statement to 
define the change. 
> The SETPROG APF operator can initiate a change to the APF table. 


The DISPLAY APF command can be used to display the list of libraries authorized by 
APF. 
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D PROG,APF 

CSV450I1 12.46.27 PROG,APF DISPLAY 027 
FORMAT=DY NAMIC 

ENTRY VOLUME DSNAME 


1 ZO4RE1 SYSI1.LINKLIB 

2 ZO4RE1 SYSI.SVCLIB 

3 ZO4RE1 ANF.SANFLOAD 

4 ZO04RE2  AOP.SAOPLOAD 

5 ZO4RE1 AOP.SAOPLOAD 

6 ZO4RE1 ARTURO.BFSLMOD 

7 ZO4RE1 ASMA.V1IR2M0.SASMMOD1 
8 TOTDBZ ASN.V7R1M0.SASNALNK 

9 TOTDBZ ASN.V7R1M0.SASNLLNK 


10 TOTDBZ ASN.V8R1IM0.SASNLOAD 
11 TOTPT1 ASNA.VS5RIMO.SASNALNK 
12 TOTPT1 ASNL.V5RIMO.SASNLLNK 


Figure 18-8 Output of D PROG APF command 


18.7.2 Storage protection 
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The zSeries hardware has a storage protection function. It is normally used to prevent 
unauthorized alteration of storage. It can also be used to prevent unauthorized reading of 
storage areas, although z/OS protects only small areas of storage this way. Storage 
protection works on 4K pages. Storage protection deals only with real memory, not 
virtual memory. When a page of virtual memory is copied from disk to a free page in 
main storage z/OS also sets an appropriate storage protection key in that page of main 
storage. 


Storage protection was much more significant before multiple address spaces came into 
use. When multiple users and jobs were in a single address space (or in real memory in 
the days before virtual memory) protecting a user’s memory from corruption (or 
inappropriate data peeking) was critical. With z/OS, the primary protection for each 
user’s memory is the isolation provided by multiple address spaces. 


Storage protection keys cannot be altered by application programs. There is no way, 
using the storage protection function, for a normal application program (that is, not an 
authorized program) to protect part of its virtual memory from other parts of the 
application in the same address space. 


An additional storage protection bit (for each 4K page of real memory) is the page 
protection bit. This prevents even system routines (running in key 0, which can normally 
store anywhere) from storing in the page. This bit is typically used to protect LPA pages 
from accidental damage by system routines. 
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18.7.3 Cross-memory communication 


With proper page table management by the operating system, users and applications in 
different address spaces are completely isolated from each other. One exception to this 
isolation is the common area. Another exception is cross-memory communication. 


With proper setup by the operating system, it is possible for a program in one standard 
address space to communicate with programs in other address spaces. A number of 
cross-memory capabilities are possible, but two are commonly used: 


¢ The ability to call a program that resides in a different address space 
¢ The ability to access (fetch, store) virtual memory in another address space 


The first case uses the program call (PC) instruction. Once the proper setup has been 
completed by z/OS, only a single hardware instruction is needed to call a program in 
another address space. A common example of this involves DB2, the major IBM data 
base product. Various parts of DB2 occupy up to four address spaces. Users of DB2 may 
be TSO users, batch jobs, and other middleware (such as a web server). When these users 
issue SQL instructions for DB2, the SQL interface in the application uses a program call 
to obtain services from the DB2 address spaces. 


Cross-memory programming can be rather complex and must be coordinated with z/OS 
security controls. In practice, almost all cross-memory usage is in major middleware 
products and are rarely directly used by typical application programs. 


Routine application programming seldom ventures into this area. Both the zSeries 
hardware architecture and internal z/OS design protect these functions from improper use 
and there have been no significant security or integrity concerns related to the 
cross-memory capabilities. 


18.8 Summary 


Making data secure does not mean just making confidential information inaccessible to 
those who should not see it; it means preventing the inadvertent destruction of files by 
people who may not even know that they are improperly manipulating data. Without 
better awareness of good data-security practices, profits obtained with technology 
evolution could result in a higher likelihood of unauthorized persons accessing, 
modifying, or destroying data, either inadvertently or deliberately. The Security Server 
is a set of features in z/OS that provides security implementation. 


The system authorization facility (SAF) is part of the z/OS operating system and 
provides the interfaces to the callable services provided to perform authentication, 
authorization and logging. 


Chapter 18. Securityon z/OS 18-23 


Chapter18 security.fm Draft Document for Review December 3, 2004 3:15 pm 


18-24 


The Resource Access Control Facility (RACF) is a component of the Security Server for 
z/OS and controls access to all protected z/OS resources. RACF protects resources by 
granting access only to authorized users of the protected resources and retains 
information about the users, resources, and access authorities in specific profiles. 


RACF provides the tools and database to allow the program products such as TSO, CICS 
and DB2 to check and verify a user’s access level and thus permit or deny the use of data 
sets, transactions or database views. 


RACF enables the organization to define individuals and groups who use the system 
RACF protects. For example, for a secretary in the organization, a security administrator 
uses RACF to define a user profile that defines the secretary’s user ID, initial password, 
and other information. 


To accomplish its goals, RACF gives you the ability to: 


Identify and authenticate users 

Authorize users to access the protected resources 

Log and report various attempts of unauthorized access to protected resources 
Control the means of access to resources 


vvvy 


Over the past several years, it has become much easier to create and access computerized 
information. No longer is system access limited to a handful of highly skilled 
programmers; information can now be created and accessed by almost anyone who takes 
a little time to become familiar with the newer, easier-to-use, high-level inquiry 
languages. As a result of this improved ease of use, the number of people using computer 
systems has increased dramatically. 


More and more people are becoming increasingly dependent on computer systems and 
the information they store in these systems. As the general computer literacy and the 
number of people using computers has increased, the need for data security has taken on 
a new level of importance. No longer can the installation depend on keeping data secure 
simply because no one knows how to access the data. 


Further, making data secure does not mean just making confidential information 
inaccessible to those who should not see it; it means preventing the inadvertent 
destruction of files by people who may not even know that they are improperly 
manipulating data. 


The authorized program facility (APF) allows special tasks running special programs to 
access sensitive system functions. APF was designed to avoid integrity exposures. The 
authorized program facility allows your installation to identify system or user programs 
that can use sensitive system functions. 


Libraries that contain authorized programs are know as authorized libraries. 
APF-authorized programs must reside in one of the following authorized libraries: 
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SYS1.LINKLIB 

SYS1.SVCLIB 

SYS1.LPALIB 

Authorized libraries specified by your installation 


vvvy 


You can use the following ways to update the content of the APF table dynamically: 


> Use PROGxx parmlib member which includes the appropriate APF statement to 
define the change. 
> The SETPROG APF operator can also initiate a change to the APF table. 


The DISPLAY APF command can be used to display the list of libraries authorized by 
APF. 


The operation of a z/OS system involves the following: 


> Console operations or how operators interact with z/OS to monitor or control the 
hardware and software 

> Message and command processing that forms the basis of operator interaction with 
z/OS and the basis of z/OS automation 


Operating z/OS involves managing hardware such as processors and peripheral devices 
and software such as the z/OS operating control system, the job entry subsystem and all 
the applications that run on z/OS. 


When implementing the console security the installation can controls which commands 
operators can enter on their consoles to monitor and control z/OS. Basically, the 
customization is made in the RACF and in the CONSOLxx member in PARMLIB. 








Key terms in this chapter 
RACF SAF SVC 


user ID password APF 




















18.9 Discussion questions 


1. On other platforms, how do you protect data sets or files? Is there a way to prevent 
the execution of a specific application? 
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2. Is the next sentence true or false? 


The access information in the resource profiles can be set only at group level. It 
means that is impossible for a single user have the update attribute to a specific data 
set if the RACF group to which he is connected has only the read attribute. 


. RACF permits you to assign the group administrator attribute to users. With this, it is 


possible to implement a decentralized administration. Discuss the pros and cons. 


. In the following situation, what will occur with the program if no authorized SVC or 


special functions are invoked? 
— one program link-edited with AC=0 and 


— running from an APF-authorized library 


. Inthe following example, what are the possible problems in a program executing 


from a library called SYS1.LINKLIB located in the volume MPRES2? 


D PROG,APF,ENTRY=1 
CSV4501 05.24.55 PROG,APF DISPLAY 979 
FORMAT=DYNAMIC 
ENTRY VOLUME DSNAME 
1 MPRES1 SYS1.LINKLIB? 


18.10 Exercises 
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. Try to log into TSO after changing the initial logon procedure IKJACCNT to 


IKJACCN1. 
The expected message is: 


1KJ56483I THE PROCEDURE NAME IKJACCN1 HAS NOT BEEN AUTHORIZED FOR THIS 
USERID 


. Using your TSO user (now with your default logon procedure IKJACCNT) try to 


delete the dataset ZPROF.JCL.NOT.DELETE, which is set up by the standard jobs in 
the supplied JCL. 


This is a protected dataset and you can only read its content. 


. Execute the next sample JCL to obtain a DSMON utility report with the current 


RACF group tree structure: (available in the sample JCL as member DSMON) 


//DSMONRPT JOB (POK,999) , 'DSMONREPORT' ,MSGLEVEL=(1,1) ,MSGCLASS=X, 

// CLASS=A,NOTIFY=&SYSUID 

/*JOBPARM SYSAFF=* 

LT? 

//* NOTE: 

//* REMEMBER THAT ICHDSMOO MUST BE RUN BY A USER WITH AUDITOR ATTRIBUTE 
//* 

//STEPNAME EXEC PGM=ICHDSMOO 
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//SYSPRINT DD SYSOUT=A 
//SYSUT2 DD SYSOUT=A 
//SYSIN DD * 
FUNCTION RACGRP 
/* 
4. Verify if the SYS1.LINKLIB library is an APF-authorized library. 


— Using DISPLAY APF command to display entire APF list 

— Using the ENTRY= operand in DISPLAY APF command 

— Using the DSNAME= operand in DISPLAY APF command. Verify the entry 
number in the command display result in syslog. 


5. The following JCL example can be used to invoke the ADRDSSU utility and issue a 
WTOR message in the console. The WTOR command lets you write an ADRI12A 
message to the system console. The ADR112A message requests that the operator 
perform some action, and then issue a reply. You can use WTOR, for example, to 
request that the operator mount a required volume or quiesce a data base before your 
DFSMsSdss job continues to process. (Available in the sample JCL as member 
ADRDSSU) 


//WTORTEST JOB (POK,999),'USER' ,MSGLEVEL=(1,1) ,MSGCLASS=X, 
// CLASS=A,NOTIFY=&SYSUID 

ae EXEC PGM=ADRDSSU 

//SYSPRINT DD SYSOUT=* 

//SYSIN. DD * 

WTOR 'TEST! 

/* 


DFSMsSadss assigns the following routing code to the WTOR message: 
1 Master console action 

DFSMSadss assigns the following descriptor code to the WTOR message: 
2 Action that is required 


In the SDSF main screen, choose the SR option (System requests) and reply with any 
response you want. 
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18.11 Instructor Notes 


18.11.1 Answers to “Discussion questions” on page 18-25 


Re 19.9 Q2 


It is possible for users to be granted personal access of UPDATE even though the group 
to which they are connected have READ. Any personal access will take precedence over 
group access. It is also possible to prevent a particular user from having any access by 
giving then NONE whilst the rest of the group have READ. 


Re 19.9 Q4 


As no special functions are used then there will be no problems executing the program, 
however if it did try to use these function as it is not authorized then the program would 
fail. 


Re 19.9 Q5 

The SYS1.LINKLIB that is authorized is on a different volume. Therefore the one in use 
is NOT authorized. So any program run from this library is also NOT authorized and use 
of special functions and SVC would lead to abnormal ending (ABEND) of the program. 


18.11.2 DCE Security Server 


You can configure your DCE cell with a security server on the mainframe, the central 
z/OS enterprise server. Availability of this critical DCE technology component on z/OS 
provides the following benefits: 


> You can keep servers and data on your z/OS systems safe from accidental or 
malicious loss, and secure from outside attack (disclosure or corruption). 

> System/390 and zSeries 900 are scalable and many z/OS systems are large. You can 
build DCE cells that are able to handle large numbers of accounts. 


z/OS is more reliable than any other system currently offering DCE. Therefore, a security 
server on z/OS is more reliable and available than on any other DCE system, giving you 
the reliability you need to run mission-critical applications in a DCE environment. 


18.11.3 LDAP 
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The LDAP server provides the following functions: 


Interoperability with other LDAP clients 

Access controls on directory information 

Secure Sockets Layer (SSL) communication (SSL V3 and TLS V1) 
Start TLS activation of secure communication 


vvvy 
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Client and server authentication using SSL/TLS 
Password encryption 

Replication 

Referrals 

LDAP Version 2 and Version 3 protocol support 
Schema publication and update 

Kerberos authentication 

Native authentication 

CRAM-MDS (Challenge-Response Authentication Method) and DIGEST-MD5 
authentication 

Root DSE information 

> LDAP access to information stored in RACF® 

> Use of DB2® data sharing in sysplex configurations 


vvvvvvvvy 
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18.11.4 2/OS firewall technologies 


The traditional firewall functions act as a blockade between your intranet (a secure, 
internal private network) and another (nonsecure) network or the Internet. The purpose of 
a firewall is to prevent unwanted or unauthorized communication into or out of the 
secure network. The firewall has two jobs: 


> The firewall lets users in your own network use authorized resources from the outside 
network without compromising your networks data and other resources. 

> The firewall keeps users who are outside your network from coming in to 
compromise or attack your network. 


18.11.5 Open Cryptographic Enhanced Plug-ins multi-subsystem 
scope (OCEP) 


This consists of two service provider modules (which are also called “plug-ins”) that are 
intended to be used with the Open Cryptographic Services Facility (OCSF) 
Framework: 


> Trust Policy 
> Data Storage Library 


These service provider modules enable applications to use z/OS Security Server (RACF), 
or equivalent product, to provide security functions for digital certificates and key rings. 


In addition to the OCSF Framework, the OCEP service provider modules are intended to 


work with the OCSF Certificate Library and Cryptographic Service Provider modules 


18.11.6 Network authentication service for z/OS 


These services include native Kerberos application programming interface (API) 
functions, as well as the Generic Security Service Application Programming Interface 
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(GSS-API) functions defined in Internet RFC 2078, Generic Security Service 
Application Program Interface, Version 2 and Internet RFC 2744, Generic Security 
Service API Version 2: C-bindings. 


18.11.7 Enterprise Identity Mapping 


EIM is an architecture for describing the relationships between individuals or entities 
(like file servers and print servers) in the enterprise and the many identities that represent 
them within an enterprise. In addition, EIM provides a set of APIs that allow applications 
to ask questions about these relationships. 


18.11.8 PKI Services 


Your users can use a PKI Services application to request and obtain certificates through 
their own Web browsers, while your authorized PKI administrators approve, modify, or 
reject these requests through their own Web browsers. The Web applications provided 
with PKI Services are highly customizable, and a programming exit is also included for 
advanced customization. You can allow automatic approval for certificate requests from 
certain users and, to provide additional authentication, add host IDs, such as RACF user 
IDs, to certificates you issue for certain users. You can also issue your own certificates 
for browsers, servers, and other purposes, such as virtual private network (VPN) devices, 
smart cards, and secure e-mail. PKI Services supports Public Key Infrastructure for 
X.509 version 3 (PKIX) and Common Data Security Architecture (CDSA) cryptographic 
standards. 


18.11.9 RACF Logging and Reporting 
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You can list the contents of these records. You can use them to help you to detect possible 
security exposures or threats. You can verify the security of the system. Each of the 
following programs can help you accomplish your goals, depending on your specific 
needs: 


> SMF data unload utility: Process SMF records and permits more complex auditing 
than the RACF report writer. The output of this utility can be: 


— Viewed directly 

— Used as input for installation-written programs 
— Manipulated by sort/merge utilities 

— Uploaded to a database manager, such as DB2 


> RACF report writer: lists the contents of SMF records in a format that is easy to 
read. The RACF report writer can also generate reports based on the information in 
the SMF records, such as: 
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— Reports that describe attempts to access a particular RACF-protected resource in 
terms of user identity, number and type of successful accesses, and number and 
type of attempted security violations 

— Reports that describe user and group activity 

— Reports that summarize system use and resource use. 


> Data security monitor (DSMON): enables you to verify the basic system integrity 
and data-security controls. RACF auditors can use the DSMON reports to evaluate 
the level of security at the installation and to compare the actual level of security at an 
installation with the planned level of security. 


> DFSORT ICETOOL: RACF uses the DFSORT ICETOOL to produce reports from 
both SMF data unload and database unload information. The information gathered is 
used by the RACF ICE procedure, which is shipped in the IRRICE member of 
SYS1.SAMPLIB. 


18.11.10 RACF sysplex data sharing 


In a Z/OS sysplex with many systems sharing the RACF database, problems can arise in 
the areas of system performance, management, and availability. RACF sysplex data 
sharing addresses these problems with: 


> Sysplex command propagation 
> The coupling facility 


Sysplex command propagation 

When you issue the RVARY command or certain SETROPTS commands on one system, 
RACF communicates the command throughout the sysplex. You do not need to issue the 
command on every system. 


If hardware or software problems require you to switch to the backup database, you can 
do so with a single RVARY command and a single response to an operator prompt. 
RACF switches all the systems in the sysplex, giving them immediate access to the 
backup database. 


Regardless of whether the coupling facility is in use, sysplex data sharing allocates local 
buffers to backup data sets. The use of local buffers can improve performance during I/O 
to the backup data sets. 


The Coupling Facility 

RACF sysplex data sharing uses the coupling facility to improve performance. When the 
system is in data sharing mode, the coupling facility provides a large central buffer for 
RACF database records. The large buffer can hold more of each system's database than 
the system's own small local buffer, and permits you to share the buffered information 
with other systems. 
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18.11.11 RRSF 


A wealth of SAMPLIB materials makes it easy to setup and use common RRSF 
configurations and options. 
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Data sharing mode is only part of sysplex data sharing. When the system is in data 
sharing mode, the coupling facility is installed and available. A system enabled for 
sysplex data sharing can perform data sharing functions that do not require the coupling 
facility, such as sysplex command propagation, regardless of whether the system is in 


data sharing mode. 


RRSF Nodes 


The RRSF network consists of a collection of nodes. Each node consists of one or more 
z/OS system images and uses a specific RACF database. All RRSF nodes work in local 


or remote mode, depending on how they're configured. 
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Figure 18-9 RACF remote sharing facility example 


In this example of an RRSF network: 
> Nodes A, B, C, and E are z/OS systems with their own RACF databases. They are 


singlesystem nodes. 


> Node D consists of two z/OS systems sharing a RACF database. It is a multisystem 


node. 
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If you are at Node A, all other nodes are considered to be remote nodes, and Node A is 
known as the local node. RRSF allows you to administer both the local and remote 
nodes. 


Remote Administration 
The RRSF environment gives you the ability to administer remote systems. With RRSF, 
you can perform several actions for administration. 


Password synchronization 

In a remote sharing environment, you can ask RACF to synchronize passwords for 
specific user IDs. When you change one password, RACF can change the passwords for 
your user ID on different nodes or for several user IDs on the same node. This provides 
improved usability. 


Command direction 


Command direction allows you to issue the same command on multiple databases and to 
send a command from one system to another. For example, if several systems need the 
same database information and you are not using automatic command direction, you can 
administer several RACF databases from a central location. This provides improved 
usability because administrators no longer need to logon to multiple systems. 


Automatic command direction 


Automatic command direction allows you to issue the same command on multiple 
databases automatically. It improves availability and performance by enabling you to use 
separate databases that are synchronized to contain the same information. 


It is especially useful in recovery or back-up situations or when you want the same 
database contents but cannot share physical DASD. 


Automatic direction of application updates 

Automatic direction of application updates allows you to automatically propagate RACF 
database updates made by applications. It is related to automatic command direction and 
improves availability and performance by enabling you to use separate databases that are 
synchronized to contain the same information. 


Automatic password direction 

Automatic password direction allows you to change passwords for the same user ID on 
different nodes automatically. If you used automatic password direction with automatic 
command direction, it improves availability and performance by keeping several 
databases synchronized with the same password information. 
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18.11.12 Link-editing modules with AC=1 


You can use the PARM field on the link-edit step to assign the APF-authorization code to 
a load module. To assign an authorization code using JCL, code AC=1 in the operand 
field of the PARM parameter of the EXEC statement. 


//LKED EXEC PGM=HEWL,PARM='AC=1',... 


This method causes the system to consider every load module created by the step to be 
authorized. 


The authorization code of a load module has meaning only when it resides on an 
APF-authorized data set and when the load module executes as the first program of a 
job-step attach. If no authorization code is assigned in the linkage editor step, the system 
assigns the default of authorized. Thus, if a load module tries to execute functions or 
SVCs that require authorization, the system abnormally ends the program and issues 
abend code X'306' reason code X'04'". 


18.11.13 IEAAPFxx parmlib member coding 


18-34 


Use the IEAAPFxx member in the SYS1.PARMLIB to specify program libraries that are 
to receive APF authorization. List the data set names of the libraries, along with the 
volume where the library resides. 


To specify the volume where the library resides, use one of the following: 
> The volume serial number of the volume on which the library resides. 


> Six asterisks (******) to indicate that the library resides on the current SYSRES 
volume. 


> *MCAT* to indicate the library resides on the volume on which the system master 
catalog resides. 


> Nothing after the library name, to indicate that the library is managed by the storage 
management system (SMS). 


Following is an example of the IEAAPFxx: 


Menu Utilities Compilers Help 

BROWSE SYS1.PARMLIB(PROGTT) - 01.01 Line 00000000 Col 001 080 
Command ===> Scroll ===> PAGE 
KREKKEKKEKKEKREKKRKEKRKREKEKRERERE Top of Data KRKKKKERKEKEKKEEKKERKEKEREKERERRRERKRKREEKE 


SYS1.VTAMLIB eee 


SYS1.SICELINK Seen ER 
SYS1.LOCAL.VTAMLIB TOTCAT, 
ISP.SISPLOAD *MCAT* 
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18.11.14 Coding and using the PROGxx parmlib member 


As mentioned in the previous section, you can use the APF statement to add or delete 
libraries from the APF list. 


To delete a library from the APF list use the following command: 


Example of a PROGxx statement using the APF DELETE command: 
APF DELETE DSNAME(SCRIPT.R40.DCFLOAD) VOLUME (MPRES2) 


Activate the change by using a SET PROG=xx command as follows: 


SET PROG=TT 

TEE2521 MEMBER PROGTT FOUND IN SYS1.PARMLIB 

CSV410I DATA SET SCRIPT.R40.DCFLOAD ON VOLUME MPRES2 DELETED FROM APF LIST 
TEE5361 PROG VALUE TT NOW IN EFFECT 


To add a library to the APF list use the following command: 


Example of a PROGxx statement using the APF ADD command: 
APF ADD DSNAME(MYPROG.LOADLIB) VOLUME (MPRES3) 
Activate the change by using a SET PROG=xx command as follows: 


SET PROG=xx 

IEE252I MEMBER PROGxx FOUND IN SYS1.PARMLIB 

CSV410I DATA SET MYPROG.LOADLIB ON VOLUME MPRES2 ADDED TO APF LIST 
IEE536I PROG VALUE xx NOW IN EFFECT 


Using the SETPROG APF command 
Use the SETPROG APF operator command to perform the following functions: 


> 


> 
> 


Change the format of the authorized program facility (APF) list from static to 
dynamic, or static to dynamic. 

Add a library to a dynamic APF list. 

Delete a library from a dynamic APF list. 


Syntax for SETPROG APF command: 


SETPROG APF{ , FORMAT={DYNAMIC| STATIC} } 
{, {ADD| DELETE} , DSNAME| LIBRARY=1 ibname, {SMS | VOLUME=vol ume} } 


To change the format of the APF list to dynamic: 


SETPROG APF, FORMAT=DYNAMIC 
CSV4101I APF FORMAT IS NOW DYNAMIC 


To add a library to the APF list: 


SETPROG APF,ADD,DSNAME=SCRIPT.R40.DCFLOAD, VOLUME=MPRES2 
CSV410I DATA SET SCRIPT.R40.DCFLOAD ON VOLUME MPRES2 ADDED TO APF LIST 
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To delete a library from the APF list: 


SETPROG APF,DELETE,DSNAME=SCRIPT.R40.DCFLOAD, VOLUME=MPRES2 
CSV410I DATA SET SCRIPT.R40.DCFLOAD ON VOLUME MPRES2 DELETED FROM APF 


Note: If you try to add or delete from an APF list that is in static format, the system 
responds with a CSV411I message, as follows: 

SETPROG APF,DELETE,DSNAME=SCRIPT.R40.DCFLOAD, VOLUME=MPRES2 

CSV4111 ADD/DELETE IS NOT ALLOWED BECAUSE APF FORMAT IS STATIC 


Using the DISPLAY APF command 


You can use the DISPLAY APF command to display one or more entries in the list of 
APF-authorized libraries. Each entry in the APF list display contains: 


> An entry number 

> The name of an authorized library 

> An identifier for the volume on which the authorized library resides (or *SMS*, if the 
library is SMS-managed) 


Syntax for DISPLAY APF command: 


D PROG,APF[,ALL ] |,DSNAME=libname |,ENTRY=xxx |,ENTRY=(xxx-yyy) ] 
»L={a|cc|cca|name|name-a} ] 


To display the whole APF list: 


D PROG, APF 
CSV4501 05.18.16 PROG,APF DISPLAY 971 
FORMAT=DYNAMIC 
ENTRY VOLUME DSNAME 
1 ZO4RE1 SYS1.LINKLIB 
2 ZO4RE1 SYS1.SVCLIB 
3 ZO4RE1 CPAC.LINKLIB 


36 MPRES2 NETVIEW.V2R4M0.USERLNK 
37 MPRES2 NPM.V2R3M0.SFNMLMD1 
38 MPRES2 EMS.V2R1M0.SEMSLMDO 


This number is the decimal entry number for each of the libraries defined in the APF list. 


To display all the libraries in the range from 1 to 5: 


D PROG,APF,ENTRY=(1-5) 
CSV450I 05.26.27 PROG,APF DISPLAY 981 
FORMAT=DYNAMIC 
ENTRY VOLUME DSNAME 
1 ZO4RE1 SYS1.LINKLIB 
2 ZO4RE1 SYS1.SVCLIB 
3 ZO4RE1 CPAC.LINKLIB 
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4 ZO4RE1 ISF.SISFLOAD 
5 ZO4RE1 ISF.SISFLPA 


18.11.15 Operator console command levels 


To authorize which of the command groups an operator can enter on an MCS or SMCS 
console, use the following keyword on the CONSOLE statement. 


AUTH 
Defines the command authority for an MCS or SMCS console 
Options you can specify for AUTH include the following: 


MASTER 


Specifies that the console has master authority. You can enter any z/OS operator 
command from the master console. 


INFO 


Specifies that the console can issue any informational commands and is the default 
value 


SYS 


Specifies that the console can issue system control commands and informational 
commands 


IO 


Specifies that the console can issue I/O control commands and informational 
commands 


CONS 


Specifies that the console can issue console control commands and informational 
commands 


ALL 


Specifies that the console can issue informational, system control, I/O control, and 
console control commands 


Operators can use the VARY CN command to change AUTH. 
18.11.16 Limiting command authority 


An installation can audit the use of commands and limit the use of commands by operator 
as well as by console: 
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> Based on the identity of the issuer of the command — who issued the command. 
Using this method, the installation can verify that the operator who issues a command 
is authorized to do so and optionally produce audit records that log command activity. 
The installation can control who can issue what commands at several different levels. 
For example, all operators might be allowed to issue all commands, some operators 
might be allowed to enter only a subset of the allowable commands, or some 
commands might be restricted to just one or two individual operators. 


> Based on the MCS console device number or the console name used to enter the 
command — where the command was issued. Using this method, the installation can 
verify that the command has been issued from a console that is authorized to issue the 
command and optionally produce audit records that log command activity. 


> Based on both the identity of the command issuer and the console device number or 
console name used to enter the command — both who issued the command and 
where the command was issued. Using this method, the installation can verify that the 
operator who issues a command is authorized to do so and that the command has been 
issued from a console that is authorized to issue the command. Audit records can log 
command activity. 


18.11.17 More information about defining RACF profiles 
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Defining Users with RACF 


Your installation’s security policy determines how you define the operators, MCS 
consoles, or SMCS consoles for automatic logon. If your installation’s security policy 
requires you to audit all operator commands according to the identity of the user, then all 
operators as individual users must be defined. If your installation uses the 
LOGON(AUTO) option in CONSOLxx to automatically log on MCS and SMCS 
consoles when they are activated, you must ensure that a user profile exists for each 
console to be logged on. 


You can also grant access to commands to groups of operators. A RACF group defines a 
set of related individuals who have similar security requirements. Defining access 
authority by group minimizes changes to the RACF profiles when individual users 
change job responsibilities or leave a particular job. 


To create profiles for operators, the RACF security administrator needs to know 


> Who the operators are 
> Which operators fall into groups with identical access requirements. 


Defining TSO/E Users of Extended MCS Consoles with RACF 


Your TSO or RACF security administrator should define user profiles for all TSO/E 
users of extended MCS consoles. TSO/E logon can be controlled through TSO/E or 
RACF, and like operators, you can define TSO/E users by individual or group profiles. 
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Your installation authorizes the TSO/E user to be able to issue the TSO/E CONSOLE 
command. This command initiates an extended MCS console session. 


Defining Commands with RACF 

Your installation’s security policy determines which commands you must protect. A 
RACF profile for the command in the OPERCMDS class protects the command. When 
an operator logs on to a console and issues a z/OS command that requires a higher 
authority than the console allows, RACF can check the access list of the command 
profile to determine if the user is authorized to issue the command. 


To link the command the operator issues with the profile that protects the command, 
z/OS provides a construct, or structure, called a resource-name for each command. 


The resource-name for a z/OS command has the following parts: 


MVS.command.command-qualifier.command object 
where: 


MVS 


Is the high-level qualifier that defines the command as a system command. MVS is a 
required part of the resource-name. Subsystem commands use a different high-level 
qualifier, such as JES2 or JES3. 


command 


Specifies the command or a specific variation of the command. To protect an 
individual command, this part of the resource-name is required. It also allows you to 
control significant variations of a command separately. For example, FORCE without 
the ARM operand has a different effect than does FORCE with the ARM operand; 
you can thus specify either FORCE or FORCEARM to control the two uses 
separately. 


command-qualifier 


Specifies a sub-function of the command. This part of the resource-name is optional. 
It allows you to protect specific command sub-functions separately. For example, the 
following resource-name protects all functions of the TRACE command: 


MVS .TRACE.** 
In contrast, the following resource-names protect each function of the TRACE 
command separately: 


MVS.TRACE.ST 
MVS. TRACE .MT 
MVS.TRACE.CT 
MVS. TRACE. STATUS 
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command-object 


Specifies the object or target of the command. This part of the resource-name is 
optional. Examples of objects or targets include: 


— The device on a CANCEL command 
— The jobname on a MODIFY command 
— The membername ona START command 


When an operator issues a z/OS command with a RACF profile, z/OS determines the 
resource-name that matches the command and passes that resource-name to RACF. 
RACF uses the resource-name to locate the profile for the command and verifies that the 
operator is allowed to issue the command by checking the access list in the profile. If 
RACF authorizes the access, z/OS processes the command; if RACF denies the access, 
z/OS rejects the command. 


Defining Consoles with RACF 


You can use a RACF profile in the CONSOLE class to determine which userids are 
authorized to log on to a particular console. The commands in the following example 
define a RACF profile for console CON1 (CONI is defined in CONSOLxx), and 
authorize userid CONSID1 to log on to that console. 


RDEF CONSOLE CON1 UACC (NONE) 
PERMIT CON1 CLASS(CONSOLE) ID(CONSID1) ACCESS(READ) 
SETROPTS CLASSACT (CONSOLE) 


Setting DEFAULT LOGON requirements for consoles 


Once you have established the RACF profiles your installation requires, you use the 
LOGON keyword on the DEFAULT statement in CONSOLxx to establish your MCS 
console operator LOGON requirements. You can: 


> Have the system automatically log each console on as the console is activated. 
Operators can log on but are not required to do so. 

> Require each operator to log on to the system before issuing commands. 

> Allow MCS console command authorization to control access to commands. 


To control how operators can log on to MCS consoles, use the following keyword on the 
DEFAULT statement in CONSOLxx: 


LOGON 
Controls the logon for operators of MCS or SMCS consoles 


Options you can specify for LOGON are as follows: 


AUTO 
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Specifies that the console is automatically logged on by its console name. In addition, 
operators can optionally log on to the console. 


REQUIRED 


Specifies that operators must log on before the system allows them to enter 
commands. If a system includes SMCS consoles, LOGON(REQUIRED) is 
recommended. 


OPTIONAL 


Specifies that operators can optionally log on to the console; otherwise, MCS console 
authority is in effect. 


The LOGON keyword affects only full-capability display consoles. 
Setting LOGON Requirements for Individual MCS or SMCS Consoles 


With z/OS, the LOGON keyword on the CONSOLE statement in CONSOLxx can 
override the system console LOGON default on the DEFAULT statement. 


To control how operators can log on to specific MCS or SMCS consoles, specify the 
following keywords on the CONSOLE statement in CONSOLExx: 


LOGON 
Controls the logon for operators of MCS and SMCS consoles 


Options you can specify for LOGON are as follows: 


AUTO 


Specifies that the console is automatically logged on. 


REQUIRED 


Specifies that the console must be logged on before commands can be issued. 


OPTIONAL 


Specifies that the console does not need to be logged on. 


DEFAULT 


Specifies that the console is to use the LOGON value on the DEFAULT statement. If 
you specify DEFAULT and the DEFAULT statement does not contain a LOGON 
value, the system issues an error message and uses LOGON(OPTIONAL) for an 
MCS console and LOGON(REQUIRED) for SMCS. 
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18.11.18 Operator console authorization (refer to 18.6.1, “Controlling 
command authority with the AUTH attribute” on page 18-1 7) 
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Assigning a console master authority 
By assigning the system command groups for a console in a system, you can establish a 
console with master authority. 


For example, to assign master authority to a console named MSTR (device number 031), 
code the following CONSOLE statement in CONSOLxx: 


CONSOLE DEVNUM(031) NAME(MSTR) AUTH(MASTER) 


If no console is defined with master authority in the system, the first full-capability MCS 
console will be made to have master authority. 


In a sysplex, the first active console with master authority in the first system that joins the 
sysplex becomes the master console. You can define AUTH(MASTER) for other 
consoles in that system or for other systems that subsequently join the sysplex. These 
consoles have master authority, but there can be only one master console in the sysplex. 


In a sysplex with only SMCS consoles, the first active console with MASTER authority 
becomes the master console. Because it is impossible to know which console will 
activate first, any console that should not be the sysplex master should not have 
MASTER authority. 


Operators can assign the master authority of a console by using the following command: 
VARY CN(name) ,AUTH=MASTER 


This command authorizes the console with master authority and establishes the 
commands that the console can receive. If a console with master authority is operating 
properly, an operator can switch to another console without disrupting normal operations. 
The operator must enter these commands through the console currently defined with 
master authority. The effect of the VARY command lasts only for the duration of the IPL. 


Controlling command authority and operator logon 

CONSOLxx provides a way to limit command authority for MCS and SMCS consoles. 
However, to control operator logon, limit the use of specific commands to specific MCS 
and SMCS consoles, or control command use for extended MCS consoles, your RACF 
security administrator can help you plan your console security. When you use RACF, you 
need to educate operators about the security policy at the installation and the changes to 
their jobs that the security policy requires. 


Your installation can use RACF and CONSOLxx to provide restrictions on the use of 
system commands to meet the security policy at your installation. If console definition 
(through the AUTH keyword) provides adequate control of command use, you need take 
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no action. Simply ensure that the LOGON parameter on the CONSOLE or DEFAULT 
statement in the CONSOLxx Parmlib member is set to OPTIONAL, which is the default. 


Protecting extended MCS consoles 

An installation can define and protect the use of extended MCS consoles through a 
security product like RACF. To define a user to RACF and control the use of the console, 
consider the following: 


1. Arrange with the RACF security administrator to define a RACF profile for the user 
of the extended MCS console. For an interactive TSO/E user, the security or TSO/E 
administrator can use RACF commands to permit the user to issue the TSO/E 
CONSOLE command. To customize the use of the TSO/E CONSOLE command, the 
user can use the TSO/E operator presentation sample defined as a series of Interactive 
System Productivity Facility (ISPF) panels in SYS1.SAMPLIB. The 
SYS1.SAMPLIB member name that contains documentation for the TSO/E operator 
presentation sample is IEATOPSD. For a z/OS application program, the administrator 
can use RACF commands to protect the use of the MCSOPER macro. In the RACF 
profile, the administrator defines the name of the extended MCS console that the 
application must specify on the MCSOPER macro. 


2. Ensure that the TSO/E user or application that acts as an extended MCS console has 
the proper console attributes. In the RACF profile for the TSO/E user or for the 
MCSOPER name that the application uses to activate the console, the RACF security 
administrator can specify the console attributes. An application program can use 
MCSOPER instead of RACF to specify these console attributes. If both RACF and 
MCSOPER define console attributes for an extended MCS console, MCSOPER 
values override the RACF values. 


18.11.19 Defining Console Attributes for Extended MCS Consoles 


If your installation uses RACF to protect extended MCS consoles, RACF maintains 
information about the console attributes in the OPERPARM segment of each RACF user 
profile. You can define or alter these attributes using the RACF ADDUSER or 
ALTUSER commands. 


MCSOPER and OPERPARM 


You can use MCSOPER to specify OPERPARM values for the extended MCS console. 
These MCSOPER values override RACF OPERPARM values for an extended MCS 
console. 


Defining RACF profiles 


To determine whether a particular user (an operator) is allowed to access a particular 
resource (a command or a console), RACF uses the RACF profiles. The security 
administrator can define a RACF profile for: 
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Each user of a console 

Each console that is to be automatically logged on 

Each z/OS command issued from a console 

Each user of the SMCS application is able to enter a command. 


vvvy 


Using RACF to authorize commands means that each operator requires an individual 
user profile. (TSO/E users of extended MCS consoles should already have a RACF 
profile in order for them to log on to TSO.) This user profile establishes the user ID of the 
individual operator, and the user ID identifies the operator when the operator logs on to 
the system. You can define the operator’s or TSO/E user’s authority to access resources 
by user ID, but you can also establish access authority through a RACF group. For 
example, if you have several operators or TSO/E users with identical access 
requirements, you can have the security administrator create a RACF group and define 
the access for the individual operators or TSO/E users through the group. 


If you want an MCS console to be automatically logged on when you specify 
LOGON(AUTO), you must ensure that each console has a user profile established for it. 
Your RACF security administrator can define a user profile by console name. When 
LOGON(AUTO) is in effect, the console is automatically logged on when it is activated. 


Resources, such as commands, MCS or SMCS consoles, and TSO terminals, also require 
RACF profiles. These profiles establish the access requirements for the resource — such 
as who can issue the command or use the console or terminal — and the level of security 
auditing your installation requires. For example, you might need to audit all uses of 
commands or want to audit only unauthorized uses of commands. 


You need to work with the RACF security administrator to set up the RACF profiles and 
options to implement your installation’s security goals. In RACF profiles that protect 
resources, the MCS authority “translates” to a RACF access authority. This RACF access 
authority is specified for a user or console in an access list of the resource profile and 
determines the command authority of the user or console. 


18.11.20 Handling Unrecognized Commands 
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To handle z/OS system commands that operators might enter but which the system does 
not recognize, create an MVS.UNKNOWN profile for RACF auditing, and define a 
universal access authority of READ. 


Some command processors, including CANCEL, FORCE, MODIFY, and STOP, will 
also use this resource when auditing unknown tasks or address spaces. 


When you specify auditing, the auditing records contain the full text of the commands 
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18.12 Storage Protection —— to 18.7.2, “Storage 
protection” on page 18-22 


In z/OS, users and jobs (each in their own address space) normally run with the same 
storage protection key. This is key 8. All the pages of the private areas of normal address 
spaces (when they are present in real memory) are set to key 8. The execution key of 
these applications (in their PSWs) is set to key 8. This means the application code can 
alter memory only in memory pages with key 8. 


z/OS uses the hardware storage protection function in the following ways: 


> The common areas of virtual memory are in protection keys | - 7. Major 
components, such as TCP/IP, have their own storage protection key in this range to 
prevent corruption by other system components. Normal applications, running in key 
8, cannot alter these areas. (When we say the common areas of virtual memory are in 
a certain protection key, we mean those pages of the common areas that are in real 
memory at any instant. The storage protection function is only for real memory.) 


> A few areas of common storage have fetch protection enabled. Normal application 
programs cannot read these areas. (Normal applications can read most of the memory 
in the common areas.) 


> High-priority functions of z/OS, such as interrupt handlers, execute in key 0. This 
means they can access and alter any real storage. 


> Storage keys 9 - 15 are not used. (An exception involves the CICS Transaction 
Server, which uses key 9 in a special way.) 


> If program attempts to alter a page that has a different protection key, a S/390 
interruption is taken and z/OS typically ABENDs the offending program. 


18.12.1 Storage protection 


Central storage, main storage, and memory are synonyms in the mainframe world. We 
tend to use memory in this text because it is the familiar term for most students. In this 
discussion memory means that portion of the total system memory that is visible to the 
processor. Considerations for LPARs, SAP memory, and expanded storage (not used by 
z/OS in zSeries machines), and unassigned memory are ignored here 


Memory provides the system with directly addressable, fast-access electronic storage of 
data. Both data and programs must be loaded into memory (from I/O devices) before they 
can be processed by the CP. The maximum memory size is restricted by hardware and 
system architecture. 


All memory locations accessed by CPs must go through storage protection checking 
before being used by a program. For each 4 KB block of memory (a page frame) there is 
a 7-bit storage key stored in separate (nonaddressable) memory. Four bits of this key are 
the access control bits. The PSW has a corresponding field, as indicated in Figure 18-10 
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on page 18-46. For every memory access, the PSW key field and the access control bits 
in the storage key are compared. If these two fields are identical the access is allowed. If 
these two fields are not identical, the CP generates an interruption and the operating 
system ABENDs the offending program. 


The operating system manages the storage protection keys and these functions are not 
seen by normal application programs 
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Figure 18-10 PSW and Storage Keys 


With z/OS all application programs operate in key 8. (Application programs are isolated 
from each other by running in different address spaces, as described in ch???.) 


z/OS usage of storage protection is a little more complex than indicated in the text. 
Almost all the memory used by the operating system (in various protection keys) are 
READ Only by user applications (which are normally in key 8) but cannot be altered by 
these users. 


Various z/OS subsystems have their own protection key so that, for example, an error in 
the communications subsystem cannot corrupt memory used by the data base subsystem. 
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Change control procedures 
on z/OS 


Objective: 
One of the strengths of the z/OS platform is stability. 


In this chapter you will learn: 


> The importance of change control 
> The concept of risk assessment 
> About Service Level Agreements 
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19.1 Introduction to change control procedures 


Data Center management is typically held accountable for service level agreements 
(SLAs). This may be through a specialist team of service managers. Change control 
mechanics and practices in a data center are implemented to ensure that SLAs are met. 


19.2 Implementation of change 


The implementation of any change must be under the control of operations. When a 
change is introduced into a production environment that results in problems or instability, 
operations staff are on the front line to observe, report and then manage the activities 
required to correct the problem or back out the change. 


19.3 Management of change 


It is common practice for data center management to have a weekly change control 
meeting to discuss, approve or reject changes. These changes might be for applications, 
system, network, hardware or power. An important part of any change is the risk 
assessment which will consider the change and evaluate from a point of view of risk to 
the system. Low risk changes may be permitted during the day whilst higher risk changes 
would be scheduled for an outage slot. It is also common practice for a data center to 
have periods of low and high risk which will influence decisions. For example if the 
system runs credit authorizations then the periods around major public holidays are 
usually extremely busy and may cause a change freeze. Also annual sales are extremely 
busy periods in retailing and may cause changes to be rejected. 


19.4 Change records 
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A change control record system is typically in place to allow for the requesting, tracking 
and approval of changes. This is usually the partner of a problem management system. 
For example if a production system has a serious problem on a monday morning one of 
the first actions will be to examine the changes that were implemented over the weekend 
to determine if these have any bearing on the problem. These records also show that the 
system is under control which is often necessary to prove to auditors especially in the 
heavily regulated financial services sector. The Sarbanes-Oxley Act 2002 in the United 
States has established the need for an effective internal control system and demonstrating 
strong change and problem management within IT services is part of compliance with 
this measure. The 8th Directive on Company Law in the European Union, which is under 
discussion at the time of writing, will address similar areas to Sarbanes-Oxley. 
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As a bare minimum there should be a set of controlled documents defined. Such a 
“change request form” should include: 


> Who - the department, group or person that requires the change, who is responsible 
for implementing the change, completing the successful test and responsible for 
backout if required. Also who will “sign off’ the change as successful. 


> What - affected system(s) or service(s) e.g. Email, File Service, domain, etc. Include 
as much detail as possible. Ideally complete instructions should be included so that 
the change could be performed by someone else in an emergency. 


> Where - Scope of change, business units, buildings, departments or groups affected or 
required to assist with the change 


> When - Start date and time and estimated duration. There are often 3 dates: requested, 
scheduled and actual 


> Priority - High, medium, low, business as usual, emergency, dated e.g. clock change 
> Risk - high, medium, low 


> Impact - what will happen if it is done; what will happen if it not done; what other 
systems may be affected; what will happen if something unexpected occurs 


> Agreed implementation instructions 


19.5 Implementation of change 


System programmers will normally raise and implement their own changes but these are 
sometimes based on a request via the change management system. Any instructions for 
operations or other groups would be in the change record and the approval of each group 
required. Implementing business application changes would normally be handled by a 
production control analyst. Application changes will normally reside in test libraries and 
an official request (with audit trail) would result in the programs in the test libraries being 
promoted to the production environment. 


Procedures involved in the change must be circulated to all interested parties. When all 
parties consider the change description to be complete then it is considered for 
implementation and then either scheduled, defered, or perhaps rejected. 


The factors which need to be considered when planning a change are: 


The benefits which will result from the change 

What will happen if the change is not done 

The resources required to implement 

The relative importance of the change request compared to others 
Any inter-dependency of change requests. 


vvvvy 
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19.6 Audit 
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Production IT systems are subject to regular audit in large enterprises. Change 
management is one of the central points. Lack of good change management procedures 
will usually result in an audit violation. Auditors will also check for the ability of 
non-operations personnel to implement change without the knowledge of operations. 


19.7 Summary 


vvvvvvvy 


Service level agreements are normally in place 
Implementation of change is controlled by operations 
Regular change control meetings are held 

Change freezes apply at critical business times 
Change must have an audit trail 

Change is implemented by an appropriate person 
Lack of good change control gives problems at audit 
Sarbanes-Oxley Act requires effective internal control 


19.8 Discussion Questions 


BW 


. Why is change control important. 
. Why does the Sarbanes-Oxley Act, which addresses corporate governance, affect 


mainframe IT. 


. What requirements would you have if you were specifying a change control system. 
. How does a change flow through such a system. Try the exercise. 
. Exercises: A paper flow exercise: 


Compose a change request 

Pass it to the appropriate group 

Update the technical content of the change 

Choose other actioners 

Choose other approvers 

Get it scheduled 

Attend change meeting 

Ensure that the change is approved by all approvers and actioners 
Perform the change 

Update the change with the status 

Propse to close the change as successful/unsuccessful 
Return the change to the requestor for closure 


roo ho ae oS 


What job roles become apparent within this exercise? 
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19.9 Instructor Notes 


Job roles within the exercise 


Change requestor 

Change driver 

Scheduler 

Change manager/co-ordinator 

Actioner 

Approver 

Reviewer/Buddy checker/Quality Assurance 
Problem manager 


Vv¥vVrVvrVrVYVYVY¥ 
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Operations 








Objective: 
All z/OS systems require human intervention but in the modern world this is reducing 


In this chapter, you will learn about: 


> Console operations 
> Automation 




















Managing the operation of z/OS in today’s data processing environment has become 
increasingly important. Operators need to learn new skills and manage more z/OS 
functions as installations grow in their computing power. Single z/OS systems are 
becoming part of multisystem environments with new demands on the management of 
the hardware, software, and people required to run those systems. To monitor z/OS and to 
respond to system changes and problems make operations planning more important than 
ever before. 


The operation of a z/OS system involves the following: 


> Console operations or how operators interact with z/OS to monitor or control the 
hardware and software. 
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> Message and command processing that forms the basis of operator interaction with 
z/OS and the basis of z/OS automation. 

> Many installations operate by exception with the operators being alerted to problems 
by automation programs. 


Operating z/OS involves managing hardware such as processors and peripheral devices 
(including the consoles where your operators do their work) and software such as the 
z/OS operating control system, the job entry subsystem, subsystems such as NetView that 
can control automated operations, and all the applications that run on z/OS. 


The z/OS environment at an installation can affect how you plan to meet your operations 
goals. Your z/OS operating environment might be a single system or a multisystem 
environment. Depending on the environment, operating z/OS can involve different 
approaches to your planning tasks. For example, planning console security for a 
multisystem environment requires more coordination than for a single z/OS system. But 
much of the planning you do for a single system can serve as the basis for planning z/OS 
operations in a multisystem environment. 


Single z/OS systems can be part of multisystem environments like a sysplex or a JES3 
complex. In a sysplex, z/OS systems can share work and resources; messages and 
commands can flow from system to system so that communication among systems is also 
shared. 


20.1 Operator Commands and Messages 


20-2 


Messages and commands form the basis of operator communication in an z/OS system or 
sysplex. Whether you are defining a console configuration for a system or for several 
systems in a sysplex, you must take into account your operators, the amount of message 
traffic they must handle, and command processing. Message routing, sending the 
appropriate messages to the right consoles, helps your operators manage work efficiently. 
Message routing using CONSOLxx can simplify the work operators need to do. 


If you want to increase system automation to simplify operator tasks, you should 
examine message flow to determine which messages you can select for your automation 
tasks and which you can suppress. Suppressing messages is important in any z/OS 
environment to spare the system operators from dealing with an excessive number of 
messages on their console screens. Message suppression also serves as a basis for your 
NetView automation planning. 


General Characteristics 


Operators can issue commands to correct problems or to query the system to determine if 
it is operating properly. They often do this in response to system messages. Some 
messages require a reply from the operator. These messages are called WTORs 
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(write-to-operator-with-reply). The operator responds to these messages by entering the 
REPLY command. Automation programs like NetView use messages and command lists 
to simplify operator tasks and actions. 


Messages and commands can be routed throughout a system or sysplex; the routing of 
messages and commands is an important part of operations planning. You want to ensure 
that operators are receiving the necessary messages at their consoles to perform their 
tasks. You want to be able to select the proper messages for suppression, automation, or 
other kinds of message processing. 


Commands in a sysplex can run on other systems and affect system processing. In a 
sysplex, operators can also route commands from one system to another for processing. 
You might want to limit command processing to a specific system in the sysplex, or 
handle commands through command installation exits. 


z/OS messages have routing codes and message levels that, in large part, determine how 
messages are routed in a system or sysplex. Routing codes are decimal numbers from | to 
128 that can be assigned to a console. Routing code functions include: 


> Indicating messages that require a specific operator action, such as routing code 1 
(master console action). 

> Indicating messages that convey information about a specific system function or 
operator area. For example, messages with routing code 6 convey information about 
the disk library. 

> Indicating an error condition. For example, messages with routing code 10 convey 
information about a system error, an uncorrectable I/O error, or information about 
system maintenance. 

> Indicating a more specific meaning. For complete information, see z/OS MVS Routing 
and Descriptor Codes. 


Message levels allow z/OS to select messages according to the severity of the condition 
or situation described in the message. Message levels can range from WTOR messages 
that require an operator response, to informational messages that indicate system status. 
You assign these levels to specific MCS, SMCS or extended MCS consoles so the system 
can direct messages at those levels to the console. For example, you can assign message 
level (R) for WTOR messages to a master console or a full-capability console that 
handles critical system messages. Assigning message levels to the appropriate consoles 
in your configuration is a good way to control message traffic for MCS, SMCS and 
extended MCS consoles. 


The system sometimes issues synchronous messages that bypass normal console 
queuing. These messages might require immediate operator action or can indicate system 
problems. You can define a group of consoles from which z/OS can select a candidate to 
display these synchronous messages. 
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20.2 Operator Responses 


When the operator issues a command in a single z/OS system, the system records the 
command in the hardcopy log if the command is eligible for recording, as specified in 
CONSOLxx. The command then flows through one or more command installation exits 
specified in MPFLSTxx. If exit processing changes the original command, the system 
issues message IEE295I and then, if the modified command is eligible for recording, 
records the command in the hardcopy log. Finally, the command processor for the 
command gets control to process the command on the system. 


The following summarizes this generalized command flow for a z/OS system: 


1. An operator or program issues the command. 

2. Depending on CONSOLxx values, hardcopy log processing records the command. 

3. Processing specified in MPFLSTxx for the command occurs. The installation exits 
specified through MPFLSTxx receive control. 

4. Ifthe exit processing modified the command, the system issues message IEE295I and 
depending on CONSOLxx values, hardcopy log processing records the command. 

5. Ifany installation exit processes the command, no further command processing 
occurs. 

6. The subsystems receive the command. 

7. Ifany subsystem processes the command, no further command processing occurs. 


The z/OS command processor receives control to process the command. 


20.3 Console Types 
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A console configuration consists of the various consoles that operators use to 
communicate with z/OS. Your installation first defines the I/O devices it can use as 
consoles with the hardware configuration definition (HCD). HCD manages the I/O 
configuration for the z/OS system. Once you have defined the devices, indicate to z/OS 
which devices to use as consoles by specifying the appropriate device numbers in the 
CONSOLxx parmlib member. 


Generally, operators on a z/OS system receive messages and enter commands on MCS 
and SMCS consoles. Operators can use other consoles such as NetView consoles, to 
interact with z/OS, but this chapter primarily describes MCS and SMCS consoles and 
how to plan for their use. Installations can enhance their z/OS operations by using 
extended MCS consoles. 


MCS consoles are devices that are locally attached to a z/OS system and provide the 
basic communication between operators and z/OS. (MCS consoles are attached to control 
devices that do not support systems network architecture (SNA) protocols.) 
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SMCS consoles are devices that do not have to be locally attached to a z/OS system and 
provide the basic communication between operators and z/OS. SMCS consoles use z/OS 
Communications Server to provide communication between operators and z/OS instead 
of direct I/O to the console device. 


In general, there are small differences in the techniques you use to define and activate 
MCS consoles and SMCS consoles. Once the consoles are activated, however, MCS 
consoles and SMCS consoles are very much alike. 


You can define MCS and SMCS consoles in a console configuration according to 
different functions. For example, one console can function as a master console for the 
system. Important messages that require action can be directed to the operator who can 
act by entering commands on the console. Another console can act as a monitor to 
display messages to an operator working in a functional area like a tape pool library or to 
display messages about printers at your installation. 


Defining a console configuration is an important part of your z/OS operations planning. 
You define a console configuration by defining the devices you want to use as consoles 
and their console attributes, in the CONSOLxx Parmlib member. In CONSOLxx, these 
console attributes control important console functions like the types of commands 
operators can enter from the console, routing information for messages and commands, 
and how to use the console. 
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Figure 20-1 


The figure shows a console configuration for a z/OS system that also includes the system 
console, an SMCS console, NetView, and TSO/E. 


The system console function is provided as part of the Hardware Management Console 
(HMC). An operator can use the system console to initialize z/OS and other system 
software and during recovery situations when other consoles are unavailable. 


In addition to MCS and SMCS consoles, the z/OS system shown in Figure has a NetView 
console defined to it. NetView works with system messages and command lists to help 
you automate z/OS operator tasks. You can control many system operations from a 
NetView console. 


Users can monitor many z/OS system functions from TSO/E terminals. Using the 
System Display and Search Facility (SDSF) and the Resource Measurement Facility 
(RMF), TSO/E users can monitor z/OS and respond to workload balancing and 
performance problems. 


An authorized TSO/E user can also initiate an extended MCS console session to interact 
with z/OS. 
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The MCS consoles in Figure include the following: 


>» An MCS master console from which an operator can view messages and enter all 
z/OS commands. This console is in full-capability mode because it can receive 
messages and accept commands. An operator can control the operations for the z/OS 
system from an MCS or SMCS master console. 

> AnMCS status display console. An operator can view system status information from 
DEVSERV, DISPLAY, TRACK, or CONFIG commands. However, because this is a 
status display console, an operator cannot enter commands from the console. An 
operator on a full capability console can enter these commands and route the output to 
a status display console for viewing. An SMCS console cannot be a status display 
console. 

> An MCS message-stream console. A message-stream console can display system 
messages. An operator can view messages routed to this console. However, because 
this is a message-stream console, an operator cannot enter commands from the 
console. You can define routing codes and message level information for the console 
so that the system can direct relevant messages to the console screen for display. 
Thus, an operator who is responsible for a functional area like a tape pool library, for 
example, can view MOUNT messages. An SMCS console cannot be a message 
stream console. 


In many installations this proliferation of screens has been replaced by operator 
workstations which combine many of these screens onto one windowed display. 
Generally the hardware console is seperate but most other terminals are combined and 
the systems managed by alerts for exception conditions from the automation product. 


The 2074 Console Support controller is the modern way of connecting consoles. It can 
replace several older control units, connecting to several images to provide consoles via a 
TN3270 connection (telnet). 


20.4 Batch jobs, Operators and automation 


At one time, many years ago, an operator would be dedicated to each console. These 
operators would watch for batch jobs failing and have to correct the job and resubmit. 
Now with systems managed by exception and one operator potentially looking after 
dozens of systems this is neither possible nor practical. In a modern system the batch jobs 
would be controlled by a batch scheduling package such as Tivoli Workload Scheduler. 
This tracks jobs as they run and if they end with a return code greater than is permitted 
for that job an alert will be raised for the operator to take action. Quite often a problem 
record will be automatically raised to track this and enable the recording of the actions 
taken. This problem record can also be passed to other groups to enable further actions to 
be taken. For example if batch jobs regularly run out of work space the problem may be 
passed to the storage support group with a request to add more volumes to the work 
pools. 
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20.5 Summary 
Operators interact with the system via messages and commands 
This is very structured which leads to message based automation 
Console types were discussed and console consolidation. 


Automation of batch jobs using a workload scheduler is necessary in today’s 
environment. 


20.6 Key terms 








Key terms in this chapter 


WTOR MPFLSTxx 




















20.7 Discussion questions 


The following questions are intended for class discussion: 
1. Why is console operations being automated ? 


2. Why does a message and command structure lend itself to automation ? 


20.8 Demonstrations 


The instructor will demonstate a number of commands and responses. Suggested 
commands: 


> DIPLINFO 
> DIOS,CONFIG 
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> $DSPOOL,ALL if running JES2 
> DC 

> DGRS,C 

> DXCF 

> DSYMBOLS 

> DAL 

> DU,TAPE 

> DASM 


20.9 Exercises 
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Using operator commands try to discover the following about your system: 


Hint: if you are using SDSF then the ULOG option gives a scrollable display of your 


commands and responses. 

1. When was it last IPL’d 

2. What level of operating system is it running 
3. Is it in a sysplex 

4. How many consoles are defined 

5. What types of tape devices are attached 

6. Is it running 31 or 64 bit 


7. How many local page datasets are there 


20.10 Instructor notes 


re 20.9 exercises 
1. When was it last IPL’d 


D IPLINFO gives this directly 
2. What level of operating system is it running 


D IPLINFO gives this 
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3. Is it in a sysplex 

D XCF and D XCF,COUPLE 

4. How many consoles are defined 

D C will display the consoles 

5. What types of tape devices are attached 

DU,TAPE 

6. Is it running 31 or 64 bit 

Little bit more esoteric D IPLINFO gives ARCHLVL: | is 31 bit; 2 is 64 bit 
7. How many local page datasets are there 


D ASM 
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Loading the system 








Objective: 


In this chapter, you will learn: 


> about the IPL process 
> why asystem would be closed down and reloaded 
> extended up time for z/OS systems 

















21.1 What is an IPL? 


Initial program loading (IPL) is the “booting” of an LPAR. The address of the DASD 
volume with the bootstrap code is entered on a panel on the hardware console and the 
LOADPARM discussed earlier in “LOADxx member” on page 17-15 is entered to define 
the hardware configuration for this LPAR. 
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Figure 21-1 IPLing the machine 





21.1.1 Initialization functions 
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Initialization Process 
The system initialization process prepares the system control program and_ its 
environment to do work for the installation. The process essentially consists of: 


> System and storage initialization, including the creation of system component address 
spaces. 
> Master scheduler initialization and subsystem initialization. 


When the system is initialized and the job entry subsystem is active, the installation can 
submit jobs for processing by using the START, LOGON, or MOUNT command. 


The initialization process begins when the system operator selects the LOAD function at 
the system console. z/OS locates all of the usable central storage that is online and 
available, and creates a virtual environment for the building of various system areas. 
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An Initial Program Load (IPL) is the act of loading a copy of the operating system from 
disk into the CPU's central storage and executing it. Not all disks attached to a CPU will 
have loadable code on them. A disk that does is generally referred to as an “IPLable” 
disk, and more specifically as the SYSRES volume. 


IPLable disks will contain a bootstrap module at cylinder 0 track 0. At IPL, this bootstrap 
is loaded into storage at real address zero and control is passed to it. The bootstrap then 
reads the IPL control program IEAIPL00 (also known as IPL text) and passes control to 
it. This in turn starts the more complex task of loading the operating system and 
executing it. 


Attempts to IPL from a disk that does not contain IPL text results in an error condition. 


IEAIPLOO prepares an environment suitable for starting the programs and modules that 
make up the operating system. First, it clears central storage to zeros before defining 
storage areas for the master scheduler. It then locates the SYSI1.NUCLEUS data set on 
the SYSRES volume and loads a series of programs from it known as IPL Resource 
Initialization Modules (IRIMs). These IRIMs will then start to construct the normal 
operating system environment of control blocks and subsystems that make up a z/OS 
system. Some of the more significant tasks performed by the IRIMs are to: 


> Read the LOADPARM information entered on the hardware console at the time the 
IPL command was executed. 


> Search the volume specified in the LOADPARM as containing the IODF data set for 
the LOADxx member-—the value of xx is also taken from the LOADPARM. IRIM will 
first attempt to locate LOADxx in SYSO.IPLPARM. If this is unsuccessful, it will 
look for SYS1.IPLPARM, and so on, up to and including SYS9.IPLPARM. If, at this 
point, it still has not been located, the search will continue in SYS1.PARMLIB. 


> When a LOADxx member has been successfully located, it will be opened and 
information including the nucleus suffix (unless overridden in LOADPARM), the 
master catalog name, and the suffix of the IEASYSxx member to be used, will be 
read from it. 


> Load the MVS nucleus. 

> Initialize virtual storage in the master scheduler address space for the System Queue 
Area (SQA), the Extended SQA (ESQA), the Local SQA (LSQA), and the Prefixed 
Save Area (PSA). At the end of the IPL sequence, the PSA will replace IEAIPL00 at 
real storage location zero, where it will then stay. 


> Initialize real storage management, including the segment table for the master 
scheduler, segment table entries for common storage areas, and the page frame table. 


The last of the IRIMs then loads the first part of the Nucleus Initialization Program 
(NIP), which then invokes the Resource Initialization Modules (RIMs), one of the 
earliest of which starts up communications with the NIP console defined in 
SYS1.NUCLEUS. 
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The system continues the initialization process, interpreting and acting on the system 
parameters that were specified. NIP (Nucleus Initialization Program) carries out the 
following major initialization functions: 


> Expands the SQA and the extended SQA by the amounts specified on the SQA 
system parameter. 

> Creates the pageable link pack area (PLPA) and the extended PLPA for a cold start 
IPL; resets tables to match an existing PLPA and extended PLPA for a quick start or a 
warm start IPL. For more information about quick starts and warm starts, see z/OS 
MVS Initialization and Tuning Reference. 

> Loads modules into the fixed link pack area (FLPA) or the extended FLPA. Note that 
NIP carries out this function only if the FIX system parameter is specified. 

> Loads modules into the modified link pack area (MLPA) and the extended MLPA. 
Note that NIP carries out this function only if the MLPA system parameter is 
specified. 

> Allocates virtual storage for the common service area (CSA) and the extended CSA. 
The amount of storage allocated depends on the values specified on the CSA system 
parameter at IPL. 

> Page protects the: NUCMAP, PLPA and extended PLPA, MLPA and extended 
MLPA, FLPA and extended FLPA, and portions of the nucleus. 


Note: An installation can override page protection of the MLPA and FLPA by specifying 
NOPROT on the MLPA and FIX system parameters. 


System Address Space Creation 

In addition to initializing system areas, z/OS establishes system component address 
spaces. z/OS establishes an address space for the master scheduler (the master scheduler 
address space) and other system address spaces for various subsystems and system 
components. Some of the component address spaces are: *MASTER*, ALLOCAS, 
APPC, CATALOG, ete. 


Master Scheduler Initialization 

Master scheduler initialization routines initialize system services such as the system log 
and communications task, and start the master scheduler itself. They also cause creation 
of the system address space for the job entry subsystem (JES2 or JES3), and then start the 
job entry subsystem. 


Subsystem Initialization 

Subsystem initialization is the process of readying a subsystem for use in the system. 
IEFSSNxx members of SYS1.PARMLIB contain the definitions for the primary 
subsystems, such as JES2 or JES3, and the secondary subsystems, such as NetView and 
DB2. For detailed information about the data contained in IEFSSNxx members for 
secondary systems, refer to the installation manual for the specific system. 
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During system initialization, the defined subsystems are initialized. You should define 
the primary subsystem (JES) first, because other subsystems, such as DB2, require the 
services of the primary subsystem in their initialization routines. Problems can occur if 
subsystems that use the subsystem affinity service in their initialization routines are 
initialized before the primary subsystem. After the primary JES is initialized, then the 
subsystems are initialized in the order in which the IEFSSNxx parmlib members are 
specified by the SSN parameter. For example, for SSN=(aa,bb) parmlib member 
IEFSSNaa would be processed before IEFSSNbb. 


START/LOGON/MOUNT Processing 


After the system is initialized and the job entry subsystem is active, jobs may be 
submitted for processing. When a job is activated through START (for batch jobs), 
LOGON (for time-sharing jobs) or MOUNT, a new address space must be allocated. 
Note that before LOGON, the operator must have started VTAM/TCAS, which have 
their own address spaces. Figure 21-2 is an illustration of some of the important system 
address spaces and then VTAM, CICS, TSO, a TSO user and a batch initiator. Each 
address space has a complete 2GB of virtual storage by default whether the system is 
running in 31-bit or 64-bit mode. 
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Figure 21-2 Virtual Storage Layout for Multiple Address Spaces 
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Each address space is mapped as shown in Figure 21-3. The private areas are available 
only to that address space but common areas are available to all. 
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Figure 21-3 The 31-bit address space 


21.1.2 Initializing the System 
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During initialization of a z/OS system, the operator uses the system console or hardware 
management console, which is connected to the support element. From the system 
console, the operator initializes the system control program during the nucleus 
initialization program (NIP) stage. 


During the NIP stage, the system might prompt the operator to provide system 
parameters that control the operation of z/OS. The system also issues informational 
messages that inform the operator about the stages of the initialization process. 


The LOADxx parmlib member allows your installation to control the initialization 
process. For example, if you specify, in LOADxx, the IEASYSxx or IEASYMxx 
members that the system is to use, the system does not prompt the operator for system 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Chapter21 ipl.fm 


parameters that are specified in those members; it uses the values in those members 
instead. 


Example 21-1 


To IPL the z/OS system, do the following: 
1. Select the IPL option 
2. IPL with the following parameters: 
o If you receive the message IEA888A for the clock, enter: 
=> r 00,u 
o If you receive the message IXC4ZOD for XCF, enter: 
=> r 00,1 
o If you receive the message IXCZ48E for XCF data sets, enter: 
=> r 00,u 
3. When the $HASP426 SPECIFY OPTIONS message appears, enter the following to 
cold start JES2: 
=> xx COLD,NOREQ 
where xx is the reply ID of the console prompt. 
Note: If the $HA 





SP454, $HASP420, $HASP441, or $HASP870 messages appear, Enter a response of Y. 


Understanding IPL Parameters 
IPL types 
There are several types of IPL: 
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> Cold Start: Any IPL that loads (or reloads) the PLPA, but does not preserve VIO data 
set pages. The first IPL after system installation is always a cold start because the 
PLPA is initially loaded. Subsequent IPLs are cold starts when the PLPA is reloaded 
either to alter its contents or to restore its contents if they were destroyed. This would 
normally be done when changes have been made to the LPA for example when a new 
SYSRES containing maintenance is being loaded. 

> Quick Start: Any IPL that does not reload the PLPA but does not preserve VIO data 
set pages. (The system resets the page and segment tables to match the last-created 
PLPA.) This would normally be done when there have been no changes to LPA but 
VIO needs to be refreshed. This prevents the warm start of jobs that were using VIO 
data sets. 

> Warm Start: Any IPL that does not reload the PLPA, but does preserve journaled VIO 
data set pages. This will allow jobs that were running at the time of the IPL to restart 
with their journalled VIO data sets. 


Note: VIO is a method of using memory to store small temporary datasets 
for rapid access. However unlike a RAM disk on a PC these are actually 
backed up to disk and so can be used as a restart point. Obviously there 
should not be too much data stored in this way so the size is restricted. 


In our collective experience over many years, the normal approach is to do a cold start 
IPL (specifying CLPA). The other options can be used but extreme care has to be taken to 
avoid unexpected change or backout of change. The warm start could be used when you 
have long running jobs which you wish to restart after IPL but an alternative approach is 
to break down those jobs into smaller pieces which pass real data sets rather than use 
VIO. Modern disk controllers with large cache memory have reduced the need for VIO 
data to be kept for long periods. Also, do not confuse a cold start IPL (CLPA would 
normally be used rather than the term cold start) with a JES cold start. Cold starting JES 
is something that is done extremely rarely on a production system, if ever, and totally 
destroys the existing data within JES. 


Specifying LOAD Information 

From the system console facility of the hardware management console, operators can 
specify the device number of the volume for the input/output definition file (IODF), 
select a LOADxx member, and control the display of messages and system prompts 
during initialization. 


The operator can specify the following values to initialize the system control program: 


The device number of the volume where the IODF, a VSAM data set that manages 
system configuration data, resides. This is also the device on which the search for the 
LOADxx member of SYSn.[PLPARM or SYS1.PARMLIB begins. For information 
about IODF and SYSn.IPLPARM, see z/OS MVS System Data Set Definition. 


> The LOADxx member of SYS1.PARMLIB or SYSn.IPLPARM 
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> The initialization message suppression indicator (IMSI) that controls the suppression 
of messages and system prompts during initialization. 

> The alternate nucleus. (This specification overrides the value specified for the 
alternate nucleus in LOADxx.) 


Operator entry of parameters 

If an IEASYSxx identifier is not specified in the LOADxx parmlib member, the operator 
is prompted to respond to the SPECIFY SYSTEM PARAMETERS message to direct the 
system components to the desired parmlib members. 


The operator can select the default general parameter list IEASYSO0, or enter 
SYSP=(aa,bb...) to select one or more alternate general parameter lists, such as 
IEASYS01, IEASYS02, and so forth. If the operator responds to the SPECIFY SYSTEM 
PARAMETERS message without specifying the SYSP parameter, then the system will 
use IEASYS00. 


The system always processes the IEASYSO0 member first, regardless of where you 
specify IEASYSxx suffixes. If the same parameter appears in both IEASYSO00 and a 
specified alternate IEASYSxx list, the value in the alternate list overrides the value in 
IEASYS00. Also, a parameter value in a later specified IEASYSxx list overrides the 
same parameter in an earlier specified list. 


Replying to IPL Messages 

The operator need not enter parameter values directly, except for those cases in which 
parameters are missing, are syntactically invalid, can’t be read, or must be supplemented 
to satisfy a special case. (An example of a special case would be the operator entry of the 
PAGE parameter to increase the amount of paging space.) 


If an error occurs with certain parmlib members, the operator is prompted to manually 
enter one or more of the member’s parameters. If the parameter can’t be corrected, the 
operator can accept the system defaults. Most parameters have defaults, either as default 
parmlib members, or as coded values in system components. If a default doesn’t exist 
(and if a parameter is not required), the operator can cancel the parameter. 


An operator-entered parameter overrides the same parameter specified in parmlib 
member IEASYS00 or IEASYSxx, except for: 


> A parameter for which operator intervention is prohibited (OPI=NO). In this case, the 
operator-entered parameter is ignored (unless the parmlib parameter was syntactically 
invalid and is being corrected from the console). 

> The PAGE parameter. The page data set names entered by the operator are added for 
the duration of the IPL to those specified in either IEASYS00 or IEASYSxx. 


Displaying IPL Parameters 
KETTNER 00000210 D IPLINFO 
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KETTNER 00000010 IEE254I 12.33.44 IPLINFO DISPLAY 466 
66 00000010 SYSTEM IPLED AT 09.09.08 ON 06/18/2004 
466 00000010 RELEASE z/OS 01.05.00 LICENSE = z/OS 
66 00000010 USED LOADZ5 IN SYS1.IPLPARM ON 9017 
466 00000010 ARCHLVL = 2 MTLSHARE = N 
466 00000010 _IEASYM LIST = (SS,Z5) 
466 00000010  IEASYS LIST = (Z5) (OP) 
466 00000010 IODF DEVICE 9017 
466 00000010 IPL DEVICE 9010 VOLUME PTSZ05 


21.1.3 The PARMLIB data sets 


The parmlib concatenation is a set of up to 16 partitioned data sets defined through 
PARMLIB statements in the LOADxx member of either SYSn.IPLPARM or 
SYS1.PARMLIB which contains many initialization parameters in a pre-specified form 
in a single logical data set, thus minimizing the need for the operator to enter parameters. 
SYS1.PARMLIB makes the 17th or last data set in the concatenation and is the default 
parmlib concatenation if no PARMLIB statements exist in LOADxx. 


Parmlib contains both a basic or default general parameter list IEASYSOO and possible 
alternate general parameter lists, called IEASYSaa, IEASYSbb, and so forth. Parmlib 
also contains specialized members, such as COMMNDxx, and IEALPAxx. Any general 
parameter list can contain both parameter values and “directors”. The directors (such as 
MLPA=01) point or direct the system to one or more specialized members, such as 
TEALPAO1. 


The parmlib concatenation is read by the system at IPL, and later by other components 
such as the system resource manager (SRM). 


21.1.4 Shutting down the system 


21-10 


z/OS systems are designed to run continuously with many months between reloads. This 
is so that important production workloads are continuously available. Change is the usual 
reason for a reload and the level of change on a system will dictate the reload schedule. 
For example: 


> A test system may be [PLed daily or even more often. 


> A high availability banking system may only be reloaded once a year, or even less 
frequently, to refresh the software levels. 


> Often outside influences may be the cause of IPLs such as the need to test and 
maintain the power systems in the machine room. 


> Sometimes badly behaved software uses up system resources which can only be 
replenished by an IPL, but this sort of behaviour is normally the subject of 
investigation and correction. 
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Many of the changes that required an IPL in the past can now be done dynamically. 
Examples of these tasks are: 


> Adding a library to the linklist for a subsystem such as CICS. 
> Adding modules to LPA 


To shut down the system each task must be closed in turn, in the correct order. On 
modern systems this is the task of the automation package. To shut down the system 
usually requires a single command. This will remove most tasks except Automation 
itself. This is closed manually and then any commands issued to remove the system from 
a sysplex or serialization ring. 


21.2 Summary 
IPL was defined 
The initialization process was explained 
Types of IPL: Cold start, quick start and warm start 
VIO was explained 


Extended uptime and reasons for IPLing 


21.3 Key terms 








Key terms in this chapter 


IPL LOADPARM Bootstrap 
IPLTEXT Nucleus SQA 
PSA VIO 




















21.4 Discussion questions 


The following questions are intended for class discussion: 
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Discuss the following statement in relation to z/OS and other operating systems you 
are familiar with : The main aim of a system programmer is to avoid system reloads. 


Why are system reloads necessary 


When would you schedule the reload of an airline reservation system. 30% of your 
business comes from Europe, 30% from Asia-Pacific and 40% from the Americas. 
Your competitors are trying to take your market share. 


21.5 Demonstration 


The instructor will demonstrate an IPL of a system. 


21.6 Exercises 
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z/OS is IPLed using the system console or the Hardware Master Console (HMC). You 
need to supply the following information to IPL z/OS. 


> 


> 


> 


The device address of IPL volume 

LOADxx member that contains pointers to system parameters 
IODF data set that contains the configuration information 
The device address of the IODF volume. 


On your system find out the IPL device address and the IPL Volume? Go to SDSF; 
issue ULOG and then /D IPLINFO. 


What is the IODF device address? 


What is the LOADxx member that was used for IPL? What is the data set that 
contains this LOADxx member. 


Browse this member and find out the name of the system catalog used by the system. 
What is the name of the IODF data set currently used? Issue /D IOS,CONFIG 


The system parameters can come from a number of PARMLIB data sets. Issue /D 
PARMLIB. What are the PARMLIB data sets used by your system? 
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21.7 Instructor Notes 


21.7.1 DAT 


DAT is dynamic address translation and is the foundation of virtual storage. Any code 
that runs is located at an address in the user’s virtual address space. When that piece of 
code is actually executed it has to be moved into real storage and the addresses 
dynamically translated to allow the code to run with those real addresses. When the piece 
of work is interupted it must be translated back to the relocatable values as it is unlikely 
that it will bebrought back to the same real location when next executed. 


Some of the nucleus is DAT-on and some is DAT-off and therefore not relocatable. The 
z/Architecture Principles of Operation, SA22-7832 has a full discussion of the topic. 
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Hardware systems and 
LPARs 








Objective: 


In this chapter, you will learn: 


about S/360 and zSeries hardware design 

about processing units and disk hardware 

how mainframes differ from PC systems in data encoding 
about some typical hardware configurations 


vvvy 




















ETC Comment: 


ARW - | don’t think this is necessary - it would over complicate the diagram which is just 


to illustrate the point - not to be all encompassing 
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This chapter looks at the hardware in a complete system, although most of the emphasis 
is on the processor “box.” 


First we must deal with a terminology problem. In the early S/360 days a system had a 
single processor and this was also known as the CPU (Central Processing Unit). The 
terms system, processor, and CPU were used interchangeably. These interchangeable 
terms have not worked well since systems became available with more than one 
processor. The problem is illustrated in Figure 22-1. 





Individual processors 
System box from IBM in the system 
possibly a zSeries machine 




















“processors” 
“CPUs" 
es a 
Sometimes referenced “PUs” 
as a “CPU” ae “CPs” 
A few people use “CEC” —”” — ZAAPS, IFLs 


Many use “system” wee 


“system” = CPs running 
an operating system 











Figure 22-1 Terminology Problem 


The basic problem is that processor and CPU can refer to either the complete system box 
or to one of the processors (CPUs) within the system box. The meaning is sometimes 
clear from the context of a discussion, but often it is not. Even mainframe professionals 
must clarify which processor or CPU meaning they are using in a discussion. IBM 
attempted to remedy the situation by introducing the term CEC (Central Electronic 
Complex) to unambiguously refer to the “box.” However, this term is not widely used. 


The use of system has obvious problems. Does it refer to the central “box” or does it 
include all the attached I/O devices? Does it refer to hardware or to an operating 
environment including an operating system and applications? 


The last few generations of S/390s and zSeries machines use the term CP to 
unambiguously refer to one of the internal processors. However, many mainframe users 
associate the CP terminology only with the partition arrangement of the system and 
dislike using the term for other purposes. The engine description is also unambiguous, 
but some people also dislike this term. 
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Partitioning and some of the terms in the figure are discussed later in this chapter. Briefly, 
all the S/390 or z/Architecture processors within a CEC are PUs (Processing Units). 
When IBM delivers the CEC the PUs are characterized as CPs (for normal work), IFLs 
(can be used for Linux), ICFs (used for Parallel Sysplex configurations), and so forth. 


We cannot solve this terminology problem. We use system and processor frequently in 
this text and we hope the meanings are clear from the context. We normally use system to 
indicate the hardware box, a complete hardware environment (with I/O devices), or a 
operating environment (with software), depending on the context. We normally use 
processor to mean a single processor (CP) within the CEC. 


22.1 Early system design 


Figure 22-2 on page 22-4 contains a conceptual diagram of a S/360 system. Current 
systems are not connected as shown in this figure. However, this figure helps explain 
background terminology that permeates mainframe discussions. 


Chapter 22. Hardware systems andLPARs 22-3 


Chapter22 hardware overview.fm Draft Document for Review December 3, 2004 3:15 pm 


22-4 





“CPU or CEC” 














Storage Main 
Control Storage 


Processors 













































































































































Parallel 
Channels—» | 1 5 6 A B 
a LN | Cc a 
t 
Ge ea i 
wens OH? 
3) Devices 0 | lly 
xX 









Co 
Control 
Unit 


communicati 





line 





Channels 

















Another 


System 














Figure 22-2 Conceptual S/360 


The central processor box contains the processor(s), memory, ! control circuits, and 
interfaces for channels. A channel provides an independent data and control path 
between I/O devices and memory. Early systems had up to 16 channels; the largest 
zSeries machines at the time of writing can have over 1000 channels. 


Channels connect to control units. A control unit contains logic to work with a particular 
type of I/O device. A control unit for a printer would have much different internal 
circuitry and logic than a control unit for a tape drive, for example. Some control units 
can have multiple channel connections providing multiple paths to the control unit and its 
devices. 


Control units connect to devices, such as disk drives, tape drives, communication 


interfaces, and so forth. The division of circuitry and logic between a control unit and its 


' Some $/360s had separate boxes for memory. However this is conceptual discussion and we ignore such 
details. 
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devices is not defined, but it is usually more economical to place most of the circuitry in 
the control unit. 


The channels in Figure 22-2 on page 22-4 are parallel channels (also known as bus and 
tag channels, named for the two heavy copper cables they use). A parallel channel can be 
connected to a maximum of eight control units. Most control units can be connected to 
multiple devices; the maximum depends on the particular control unit but 16 is a typical 
number. 


Each channel, control unit, and device has an address, expressed as a hexadecimal 
number. The disk drive marked with an X in the figure has address 132, derived as shown 
in Figure 22-3. 


address: 132 


channel number control unit number device number 
Figure 22-3 Device address 


The disk drive marked with a Y in the figure can be addressed as 171, 571, or 671 
because it is connected via three channels. By convention the device is known by its 
lowest address (171) but all three addresses could be used by the operating system to 
access the disk drive. Multiple paths to a device are useful for performance and for 
availability. When an application wants to access disk 171 the operating system will first 
try channel 1. If it is busy (or not available) it will try channel 5, and so forth. 


Figure 22-2 on page 22-4 contains another S/360 system with two channels connected to 
control units used by the first system. This sharing of I/O devices is common in all 
mainframe installations. Tape drive Z is address A31 for the first system but is address 
331 for the second system. Sharing devices, especially disk drives, is not a simple topic 
and there are hardware and software techniques used by the operating system to control 
exposures such as updating the same disk data at the same time from two independent 
systems. 


As mentioned, current mainframes are not used exactly as shown in Figure 22-2 on 
page 22-4. Differences include: 


> Parallel channels are not available on the newest mainframes and are slowly being 
displaced on older systems. 

> Parallel channels have been replaced with ESCON (Enterprise Systems CONnection) 
and FICON (FIber CONnection) channels. These channels connect to only one 
control unit or, more likely, are connected to a director (switch) and are optical fibers. 

> Current mainframes have more than 16 channels and use two hexadecimal digits as 
the channel portion of an address. 
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> Channels are generally known as CHPIDs (Channel Path Identifier)s or PCHIDs 
(Physical Channel IDs) on later systems, although the term channel is also correct. 
The channels are all integrated in the main processor box. 


The device address seen by software is more correctly known as a device number 
(although the term address is still widely used) and is indirectly related to the control unit 
and device addresses. 


For a look at the development of the IBM mainframe since 1964, see Appendix F, “A 
Little Bit of IBM Mainframe History”. 


22.2 Current Design 


Current CEC designs are considerably more complex than the early S/360 design. This 
complexity includes many areas: 


> I/O connectivity and configuration 
> I/O operation 
> Partitioning of the system 


22.2.1 I/O Connectivity 


Figure 22-4 on page 22-7 illustrates a recent configuration. (A real system would have 
more channels and I/O devices, but this figure illustrates key concepts.) Partitions, 
ESCON channels, and FICON channels are described later. Briefly, partitions create 
separate logical machines within the CEC. ESCON and FICON channels are logically 
similar to parallel channels but use fiber connections and operate much faster. A modern 
system might have 100-200 channels or CHPIDs.7 Key concepts partly illustrated here 
include the following: 


>» ESCON and FICON channels connect to only one device or one port on a switch. 

> Most modern mainframes use switches between the channels and the control units. 
The switches may be connected to several systems, sharing the control unit(s) and 
some or all of its I/O devices across all the systems. 

> CHPID addresses are two hexadecimal digits. 

> Multiple partitions can sometimes share CHPIDs. Whether this is possible depends 
on the nature of the control unit(s) used through the CHPIDs. In general, CHPIDs 
used for disks can be shared. 

> An I/O subsystem layer exists between the operating systems in partitions (or in the 
basic machine if partitions are not used) and the CHPIDs. 


? The more recent zSeries machines can have more than 256 channels, but an additional setup is needed for 
this. The channels are assigned in a way that only two hexadecimal digits are needed for CHPID addresses. 
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An ESCON director or FICON switch is a sophisticated device that can sustain high data 
rates through many connections. (A large director might have 200 connections, for 
example, and all of these can be passing data at the same time.) The director or switch 
must keep track of which CHPID (and partition) initiated which I/O operation so that 
data and status information is returned to the right place. Multiple I/O requests, from 
multiple CHPIDs attached to multiple partitions on multiple systems, can be in progress 
through a single control unit. 


EE HE OG 


Figure 22-4 Recent System Configuration 











The I/O control layer uses a control file known as an IOCDS (I/O Control Data Set) that 
translates physical I/O addresses (composed of CHPID numbers, switch port numbers, 
control unit addresses, and unit addresses) into device numbers that are used by the 
operating system software to access devices. This is loaded into the Hardware Save Area 
(HSA) at PowerOn and can be modified dynamically. A device number looks like the 
addresses we described for early S/360 machines except that it can contain three or four 
hexadecimal digits). Many users still refer to these as “addresses” although the device 
numbers are arbitrary numbers between x'0000' and x’FFFF’. The newest zSeries 
machines, at the time of writing, have two layers of I/O address translations between the 
real I/O elements and the operating system software. The second layer was added to 
make migration to newer systems easier. 
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Modern control units, especially for disks, often have multiple channel (or switch) 
connections and multiple connections to their devices. They can handle multiple data 
transfers at the same time on the multiple channels. Each device will have a Unit Control 
Block (UCB) within each MVS image. 


External device label 
Four hex digits in range 0000-FFFF 
Arbitrarily assigned by sysprog 

Used in JCL, commands, messages, 
EREP 
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Figure 22-5 Device Addressing 


22.2.2 System Control and Partitioning 


There are many ways to illustrate a zSeries mainframe’s internal structure depending on 
what we wish to emphasize. Figure 22-6 on page 22-9, while highly conceptual, 
illustrates several of the functions of the internal system controls on current mainframes. 
The internal controllers are microprocessors but use a much simpler organization and 
instruction set than zSeries processors. They are usually known as controllers to avoid 
confusion with zSeries processors. 
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Figure 22-6 System Control and Partitioning 


Among the system control functions is the capability to partition the system into several 
logical partitions (LPARs). For many years there was a limit of 15 LPARs in a system; 
more recent machines have a limit of 30 (and potentially more). Practical limitations of 
memory size, I/O availability, and available processing power usually limit the number of 
LPARs to less than these maximums. 


The hardware and firmware that provides partitioning is known as PR/SM 
(Processor Resource/System Manager). It is the PR/SM functions that are used to 
create and run LPARs. This difference between PR/SM (a built-in facility) and 
LPARs (the result of using PR/SM) is often ignored and the term LPAR is used 
collectively for the facility and its results. 


System administrators assign portions of memory to each LPAR; memory cannot be 
shared among LPARs. The administrators can assign processors (noted as CPs in the 
figure) to specific LPARs or they can allow the system controllers to dispatch any or all 
the processors to all the LPARs using an internal load-balancing algorithm. Channels 
(CHPIDs) can be assigned to specific LPARs or can be shared by multiple LPARs 
depending on the nature of the devices on each channel. 


A system with a single processor (CP processor) can have multiple LPARs. 
PR/SM has an internal dispatcher that can allocate a portion of the processor to 
each LPAR, much as an operating system dispatcher allocates a portion of its 
processor time to each process, thread, or task. 


Partitioning control specifications are partly contained in the IOCDS and are partly 
contained in a system profile. The IOCDS and profile both reside in the Support Element 
(SE) which is simply a ThinkPad (IBM laptop) inside the system. The SE can be 
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connected to one or more Hardware Management Consoles (HMCs) which are desktop 
Personal Computers. An HMC is more convenient to use than an SE and can control 
several different mainframes. 


Working from an HMC (or from an SE in unusual circumstances) an operator prepares a 
mainframe for use by selecting and loading a profile and an IOCDS. These create LPARs 
and configure the channels with device numbers, LPAR assignments, multiple path 
information, and so forth. This is known as a power-on reset (POR). By loading a 
different profile and IOCDS the operator can completely change the number and nature 
of LPARs and the appearance of the I/O configuration. Doing this is usually disruptive to 
any running operating systems and applications and this is seldom done without advance 
planning. 


22.2.3 Characteristics of LPARs 
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LPARs are, for most practical purposes, equivalent to separate mainframes. Each LPAR 
runs its own operating system. This can be any mainframe operating system; there is no 
need run z/OS, for example, in all LPARs. The installation planners may elect to share 
I/O devices across several LPARs, but this is a local decision. 


The system administrator can assign one or more system processors for the exclusive use 
of an LPAR. Alternately, the administrator can allow all processors to be used on some or 
all LPARs. In this case, the system control functions (often known as microcode or 
firmware) provides a dispatcher to share the processors among the selected LPARs. The 
administrator can specify a maximum number of concurrent processors executing in each 
LPAR. He can also provide weightings for different LPARs; for example, he can specify 
that LPAR1 should receive twice as much processor time as LPAR2. 


The operating system in each LPAR is IPLed separately, has its own copy” of its 
operating system, has its own operator console (if needed), and so forth. If the system in 
one LPAR crashes there is no effect on the other LPARs. 


In Figure 22-6 on page 22-9, for example, we might have a production z/OS in LPAR1, a 
test version of z/OS in LPAR2, and Linux for S/390 in LPAR3. If our total system has 8 
GB memory, we might have assigned 4 GB to LPAR1, 1 GB to LPAR2, | GB to LPAR3, 
and have kept 2 GB in reserve for some reason. The operating system consoles for the 
two z/OS LPARs might be in completely different locations.* 


For most practical purposes there is no difference between, for example, three 
separate mainframes running z/OS (and sharing most of their I/O configuration) 
and three LPARs on the same mainframe doing the same thing. With minor 
exceptions z/OS, the operators, and applications cannot detect the difference. 


3 Most, but not all, of the z/OS system libraries can be shared. Whether or not this is done depends on the 
system administrators. 
4 Linux does not have an operator console in the sense of the z/OS console(s). 
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The minor differences include the ability of z/OS (if permitted when the LPARs 
were defined) to obtain performance and utilization information across the 
complete mainframe system and to dynamically shift resources (processors and 
channels) among LPARs to improve performance. 


22.2.4 Consolidation of Mainframes 


There are fewer mainframes in use today than there were 15 or 20 years ago. In some 
cases all the applications were moved to other types of systems. However, in most cases 
the reduced number is due to consolidation. Several smaller mainframes have been 
replaced with a smaller number of larger systems. 


There is a compelling reason for consolidation. Mainframe software (from many 
vendors) can be very expensive and typically costs more than the mainframe hardware. It 
is usually less expensive (and sometimes much less expensive) to replace multiple 
software licenses (for smaller machines) with one or two licenses (for larger machines). 
Software license costs are often linked to the power of the system but the pricing curves 
favor a smaller number of larger machines. 


Software license costs for mainframes have become a dominant factor in the 
mainframe industry growth and direction. There are several nonlinear factors that 
make software pricing very difficult. We must remember that mainframe software 
is not a mass market situation like PC software. The growth of mainframe 
processing power in recent years has been nonlinear. 


The relative power needed to run a traditional mainframe application (a batch job 

written in COBOL, for example) does not have a linear relation to the power 
needed for a new application (with a GUI interface, written in C and Java). The 
consolidation effect has produced very powerful mainframes. These might need 
1% of their power to run an application, but the application vendor often sets a 
price based on the total power of the machine. 


This results in the odd situation where customers want the latest mainframe (to 
obtain new functions or to reduce maintenance costs associated with older 
machines) but they want the s/owest mainframe that will run their applications (to 
reduce software costs based on total system processor power). 


22.3 Processing Units 


Figure 22-1 on page 22-2 lists several different types of processors in a system. These are 
all z/Architecture processors that can be used for slightly different purposes.> Several of 
these purposes are related to software cost control and others are more fundamental. 


> Do not confuse these with the controller microprocessors. The processors discussed in this section are full, 
standard mainframe processors. 
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All these start as equivalent PUs (Processor Units)® or engines. A PU is a processor that 
has not been characterized for use. Each of the processors begins as a PU and is 
characterized by IBM during installation or at a later time. The potential 
characterizations are: 


> 


CP (Central Processor) - This is a processor available to normal operating system and 
application software. 


SAP (System Assistance Processor) - Every modern mainframe has at least one SAP 
and larger systems may have several. The SAP(s) execute internal code’ to provide 
the I/O subsystem. A SAP, for example, translates between device numbers and real 
addresses of CHPIDs, control unit addresses, and device numbers. It manages 
multiple paths to control units and performs error recovery for temporary errors. 
Operating systems and applications cannot detect SAPs and SAPs do not use any 
“normal” memory. 


IFL (Integrated Facility for Linux) - This is a normal processor with one or two 
instructions disabled that are used only by z/OS. Linux does not use these instructions 
and can be executed by an IFL. Linux can be executed by a CP as well. The 
difference is that an IFL is not counted when specifying the model number’ of the 
system. This can make a substantial difference in software costs. 


ZAAP - This is a processor with a number of functions (interrupt handling, some 
instructions) disabled such that no full operating system can be executed on the 
processor. However, z/OS can detect the presence of zAAP processors and will use 
them to execute Java code (and possibly other similar code in the future). The same 
Java code can be executed on a standard CP. Again, zAAP engines are not counted 
when specifying the model number of the system. Like IFLs, they exist only to 
control software costs. 


ICF (Integrated Coupling Facility) - These processors run only licensed internal code. 
They are not visible to normal operating systems or applications. A coupling facility 
is, in effect, a large memory scratch pad used by multiple systems to coordinate work. 
ICFs must be assigned to LPARs that then become coupling facilities. These are 
discussed in more detail in Appendix 23, “Parallel Sysplex”. 


Spare - An uncharacterized PU functions as a spare. If the system controllers detect a 
failing CP or SAP it can be replaced with a spare PU. In most cases this can be done 
without any system interruption, even for the application running on the failing 
processor. 


Various forms of Capacity on Demand and similar arrangements exist whereby a 
customer can enable additional CPs at certain times. This can be for unexpected peak 
loads, for example. 


6 This discussion applies to the current zSeries machines at the time of writing. Earlier systems had fewer 
processor characterizations and even earlier system did not use these techniques. 

7 TBM refers to this as Licensed Internal Code (LIC). It is often known as microcode (which is not technically 
correct) or as firmware. It is definitely not user code. 

8 Some systems do not have different models; in this case a capacity model number is used. 
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In addition to these various characterizations of processors, some mainframes have 
models or versions that are configured to operate slower than the potential speed of their 
CPs. This is widely known as kneecapping, although IBM prefers the term capacity 
setting or something similar. It is done by using microcode to insert null cycles into the 
processor instruction stream. The purpose, again, is to control software costs by having 
the minimum mainframe model or version that meets the application requirements. IFLs, 
SAPs, zAAPs, and ICFs always function at the full speed of the processor since these 
processors “do not count” in software pricing calculations.” 


22.4 Multiprocessors 


All the earlier discussions and examples assume that more than one processor (CP) is 
present in a system (and perhaps in an LPAR). It is possible to purchase a current 
mainframe with a single processor (CP) but this is not a typical system. !° The term 
multiprocessor means several processors (CP processors) and implies that several 
processors are used by a copy of z/OS. 


All operating systems today, from PCs to mainframes, can work in a multiprocessor 
environment. However, the degree of integration of the multiple processors varies 
considerably. For example, pending interrupts in a system (or in an LPAR) can be 
accepted by any processor in the system (or working in the LPAR). Any processor can 
initiate and manage I/O operations to any channel or device available to the system or 
LPAR. Channels, I/O devices, interrupts, and memory are owned by the system (or by the 
LPAR) and not by any specific processor. 


This multiprocessor integration appears simple on the surface but its implementation is 
complex. It is also important for maximum performance; the ability of any processor to 
accept any interrupt sent to the system (or to the LPAR) is especially important. 


Each processor in a system (or in an LPAR) has a small private area of memory (8 KB 
starting at real address 0 and always mapped to virtual address 0) that is unique to that 
processor. This is the Prefix Storage Area (PSA) and is used for interrupt handling and 
for error handling. A processor can access another processor’s PSA through special 
programming, although this is normally done only for error recovery purposes. A 
processor can interrupt other processors by using a special instruction (SIGP, for Signal 
Processor). Again, this is typically used only for error recovery. 


° This is true for IBM software but may not be true for all software vendors. 

10 All current IBM zSeries systems also require at least one SAP, so the minimum system has two processors: 
one CP and one SAP. However, the use of “processor” in the text usually a CP processor usable for 
applications. Whenever discussing a processor other than a CP, we always make this clear. 
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22.5 Disk devices 
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Current mainframes use IBM 3390 disk drives. Conceptually, this is a simple 
arrangement, as shown in Figure 22-7. 





| IBM 3990 IBM 3390 Disk Unit 
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The associated control unit (3990) typically has four channels connected to one or more 
processors (probably with a switch) and the 3390 unit typically has eight or more disk 
drives. Each disk drive has the characteristics explained earlier. This illustration shows 
3990 and 3390 units, and it also represents the concept or architecture of current devices. 
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Figure 22-7 Initial IBM 3390 Disk Implementation 


The current equivalent device is an IBM 2105 Enterprise Storage Server, simplistically 
illustrated in Figure 22-8. 
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Figure 22-8 Current 3390 Implementation 


The 2105 unit is a very sophisticated device. It emulates a large number of control units 
and 3390 disk drives. It contains up to 11 TB of disk space, has up to 32 channel 
interfaces, 16 GB cache, and 284 MB of non-volatile memory (used for write queueing). 
The Host Adapters appear as control unit interfaces and can connect up to 32 channels 
(ESCON or FICON). 
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The physical disk drives are commodity SCSI-type units (although a serial interface, 
known as SSA, is used to provide faster and redundant access to the disks). A number of 
internal arrangements are possible, but the most common involves many RAID 5 arrays 
with hot spares. Practically everything in the unit has a spare or fallback unit. The 
internal processing (to emulate 3990 control units and 3390 disks) is provided by four 
high-end RISC processors in two processor complexes; each complex can operate the 
total system. Internal batteries preserve transient data during short power failures. A 
separate console is used to configure and manage the unit. 


The 2105 offers many functions not available in real 3390 units, including FlashCopy, 
Extended Remote Copy, Concurrent Copy, Parallel Access Volumes, Multiple 
Allegiance, a huge cache, and so forth. 


A simple 3390 disk drive (with control unit) has different technology from the 2105 just 
described. However the basic architectural appearance to software is the same. This 
allows applications and system software written for 3390 disk drives to use the newer 
technology with no revisions.!! There have been several stages of new technology 
implementing 3390 disk drives; the 2105 is the most recent of these. The process of 
implementing an architectural standard (in this case the 3390 disk drive and associated 
control unit) with newer and different technology while maintaining software 
compatibility is characteristic of mainframe development. As has been mentioned several 
times, maintaining application compatibility over long periods of technology change is 
an important characteristic of mainframes. 


22.6 EBCDIC 


ETC Comment: 





'l Some software enhancements are needed to use some of the new functions, but these are compatible 
extensions at the operating system level and do not affect application programs. 
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The IBM S/360-zSeries machines use the Extended Binary Coded Decimal Interchange 
(EBCDIC) character set for most purposes. This is an 8-bit character set that was 
developed before 8-bit ASCH (American Standard Code for Information Interchange) 
became commonly used. Most systems that you are familiar with will use ASCH. You 
need to be aware of the difference in encoding when moving data from ASCI-based 
systems to EBCDIC-encoded systems. Generally the conversion is handled under the 
covers, for example when text is sent from a 3270 emulator running on a PC to a TSO 
session. However when transferring programs these must not normally be translated and 
a binary transfer must be specified. Occaisionally even when transferring text there are 
problems with certain characters such as the OR sign( |) or the logical NOT and the 
programmer must look at the actual value of the translated character. 


The EBCDIC character set is an extension of the 6-bit BCD character set that was 
widely used before the S/360 machines were developed. The BCD bit 
assignments for characters were partly related to the holes used in a punched card 
for the character. This appears to have been carried forward into EBCDIC bit 
assignments. The “gaps” in the character sequences in EBCDIC occur at the same 
places certain card row punches changed. In the early implementation of S/360 
hardware this may have saved circuitry. 


The original S/360 machines offered an ASCII option (a bit in a key control 
register) to shift from EBCDIC to the then-current 7-bit ASCII character set. It 
was used so little that the bit was later reassigned for other purposes. 


A listing of EBCDIC and ASCII bit assignments is presented in Appendix B, “EBCDIC - 
ASCII table” and may be useful for this discussion. ASCII and EBCDIC are both 8-bit 
character sets. The difference is the way they assign bits for specific characters. The 
following are a few examples: 


Character EBCDIC ASCII 
A 11000001 (x'C1') 01000001 (x'41') 
B 11000010 (x'C2') 01000010 (x'42') 
a 10000001 (x'81') 01100001 (x'61') 
1 11110001 (x'F1') 00110001 (x'31') 
Space 01000000 (x'40') 00100000 (x'20') 


The ASCH arrangement is more logical. However, the huge amount of existing data in 
EBCDIC and the large number of programs that are sensitive to the character set make it 
impractical to convert all existing data and programs to ASCII. 


A character set has a collating sequence, corresponding to the binary value of the 
character bits. For example A has a lower value than B in both ASCII and EBCDIC. The 
collating sequence is important for sorting and for almost any program that scans and 
manipulates character strings. The general collating sequence for common characters in 
the two character sets is as follows: 


EBCDIC ASCII 
Lowest value: space space 
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punctuation punctuation 

lower case numbers 

upper case upper case 
Highest value: numbers lower case 


For example, “a” is less than “A” in EBCDIC, but “a” is greater than “A” in ASCII. 
Numeric characters are less than any alphabetic letter in ASCII but are greater than any 
letter in EBCDIC. A-Z and a-z are two contiguous sequences in ASCII. In EBCDIC there 
are gaps between some letters. If we subtract A from Z in ASCII we have 25. If we 
subtract A from Z in EBCDIC we have 40 (due to the gaps in binary values between 
some letters). 


Converting simple character strings between ASCII and EBCDIC is trivial. The situation 
is more difficult if the character being converted is not present in the standard character 
set of the target code. A good example is a logical not symbol that is used in a major 
mainframe programming language (PL/I); there is no corresponding character in the 
ASCI set. Likewise, some ASCII characters used for C programming were not present in 
the original EBCDIC character set, although these were later added to EBCDIC. There is 
still some confusion about the cent sign and the hat symbol, and a few more obscure 
symbols. 


Mainframes also use several versions of Double Byte Character Sets (DBCS), mostly 
used for Asian languages. The same character sets are used by some PC programs. Both 
mainframes (using EBCDIC for single-byte characters), PCs, and various RISC systems 
use the same Unicode assignments. (Unicode provides 16-bit characters that intends to 
include all modern languages on Earth.) 


Traditional mainframe programming does not use special characters to terminate fields. 
In particular, nulls and new line characters (or CL/LF character pairs) are not used. There 
is no concept of a binary versus a text file. Bytes can be interpreted as EBCDIC or ASCII 
or something else if programmed properly. If such files are sent to a mainframe printer, it 
will attempt to interpret them as EBCDIC characters because the printer is sensitive to 
the character set. The z/OS web server routinely stores ASCH files since the data will be 
interpreted by a PC browser program that expects ASCII data. Provide that no one 
attempts to print the ASCII files on a mainframe printer (or display them on a 3270) the 
system does not care what character set is being used. 


22.6.1 Unicode 


The use of Unicode is slowly growing. The latest zSeries mainframes have a number of 
unique hardware instructions for Unicode. At the time of writing, Unicode usage on 
mainframes is primarily in Java. However, other middleware is also beginning to use 
Unicode and this is certainly an area of change for the near future. 
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22.7 Clustering 


Clustering has been done on mainframes since the early S/360 days, although the term 
cluster is seldom used. Additional clustering techniques have been added over the years. 
In the following paragraphs we will illustrate three levels of clustering: Basic Shared 
DASD, CTC Rings, and Parallel Sysplex. Most z/OS installations today use one or more 
of these levels; a single z/OS installation is relatively rare. 


In this discussion we use the term image. A functioning z/OS system (with one or more 
processors) is a z/OS image. A z/OS image might exist on a S/390 or zSeries server (with 
LPARs), or it might exist in an LPAR, or it might run under z/VM (a hypervisor 
discussed in Appendix E, “Other mainframe operating systems”). A system with six 
LPARs—each a separate z/OS system—has six z/OS images. We use the term image to 
indicate that we do not care where (basic system, LPAR, z/VM) a z/OS system is 
running. 


22.7.1 Basic Shared DASD 
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A basic shared DASD environment is illustrated in Figure 22-9. The figure indicates 
z/OS images, but these could be any earlier version of the operating system. This could 
be two LPARs in the same system or two separate system; there is absolutely no 
difference in the concept or operation. 
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Figure 22-9 Basic Shared DASD 
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The capabilities of a basic shared DASD system are limited. The operating systems 
automatically issue RESERVE and RELEASE commands to a disk drive before updating 
the VTOC or catalog on a drive. (These contain metadata for the disk drive indicating 
where various data sets reside on the drive.) A disk RESERVE command limits access to 
the complete disk drive to the system issuing the command and this lasts until a 
RELEASE command is issued. These commands work well for limited periods (such as 
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updating metadata). Applications can also issue RESERVE/RELEASE disk commands 
to protect their data sets for the duration of the application. This is not automatically done 
in this environment and is seldom done in practice because it would lock out other 
systems’ access to the drive for too long. 


A basic shared DASD system is typically used where the operations staff controls which 
jobs go to which system and they ensure that there is no conflict such that both systems 
try to update the same data at the same time. Despite this limitation a basic shared DASD 
environment is very useful for testing, recovery, and careful load balancing. 


Other types of devices or control units can be attached to both systems. For example a 
tape control unit, with multiple tape drives, can be attached to both systems. In this 
configuration the operators can then allocate individual tape drives to the systems as 
needed. 


22.7.2 CTC Rings 


Figure 22-10 illustrates the next level of clustering. This has the same shared DASD as 
discussed previously but also has two channel to channel (CTC) connections between the 
systems. This is known as a CTC ring. (The ring aspect is more obvious when more than 
two systems are involved.) 
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Figure 22-10 Basic Sysplex 















































z/OS can use the CTC ring to pass control information among all system in the ring. The 
information that can be passed this way includes: 


¢ Usage and locking information for data sets on disks. This allows the system to 
automatically prevent unwanted duplicate access to data sets. (This locking is based 
on JCL specifications provided for jobs sent to the system, as explained in 
Appendix 5, “Batch processing, JCL, and Job Management with JES”’.) 
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* Job queue information such that all the systems in the ring can accept jobs from a 
single input queue. Likewise, all systems can send printed output to a single output 
queue. 

¢ Security controls that allow uniform security decisions across all systems. 

¢ Disk metadata controls so that RESERVE and RELEASE disk commands are not 
necessary. 


To a large extent, batch jobs and interactive users can run on any system in this 
configuration because all disk data sets can be accessed from any z/OS image. Jobs (and 
interactive users) can be assigned to whichever system is most lightly loaded at the time. 


When the CTC configurations were first used the basic control information shared was 
locking information. The internal z/OS component doing this is a General Resource 
Sharing (GRS) function and the configuration became known as a GRS ring. The 
primary limitation of the ring is the latency involved in sending messages around the 
ring. 


A different CTC configuration was used before the ring technique was developed. 
This required two CTC connections from every system to every other system in 
the configuration. When more than two or three systems were involved this 
became complex and required a considerable number of channels. 


The earlier CTC configurations (every-system-to-every-system or a ring 
configuration) were later developed into a basic sysplex configuration. This 
includes control data sets on the shared DASD. These are used for consistent 
operational specifications for all systems and to retain information over system 
restarts. 


Configurations with shared DASD, CTC connections, and shared job queues are 
known as loosely coupled systems. (Multiprocessors, where several processors are 
used by the operating system, are sometimes contrasted as tightly coupled systems 
but this terminology is seldom used. These are also known as SMPs (Symmetrical 
MultiProcessors); the SMP terminology is common with RISC systems but is not 
normally used for mainframes.) 


22.7.3 Parallel Sysplex 
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The most recent cluster configuration is a Parallel Sysplex. This involves one or more 
Coupling Facilities (CFs). A Coupling Facility is a zSeries processor, with memory and 
special channels, and a built-in operating system. It has no I/O devices, other than the 
special channels, and the operating system is very small. !? 


A CF functions largely as a fast scratch pad. It is used for three purposes: 


> Locking information that is shared among all attached systems. 
> Cache information (such as for a data base) that is shared among all attached systems. 


2 The CF operating system is nothing like z/OS and has no direct user interfaces. 
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> Data list information that are shared among all attached systems. 


The information in the CF resides in memory and a CF typically has a large memory. A 
CF can be a separate system or an LPAR can be used as a CF. Figure 22-11 illustrates a 
small Parallel Sysplex with two z/OS images. Again, this whole configuration could be 
in three LPARs of a single system, in three separate systems, or in a mixed combination. 
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Figure 22-11 Parallel Sysplex 


In many ways a Parallel Sysplex system appears as a single large system. It has a single 
operator interface (which controls all systems). With proper planning and operation 
(neither of which is trivial) complex workloads can be shared by any or all systems in the 
Parallel Sysplex and recovery (by another system in the Parallel Sysplex) can be 
automatic for many workloads. 


Parallel Sysplex systems are described in more detail in Appendix 23, “Parallel Sysplex’. 
The purpose of the short introduction here is to introduce additional terminology. 


22.8 Typical Systems 
We outline the general configurations of three different levels of configurations in this 


section. These are not intended to be detailed descriptions but are simply overviews. 


22.8.1 Very Small Systems 


The first examples, in Figure 22-12 on page 22-22, illustrate that mainframe refers more 
to a style of computing rather than to unique hardware. Two different systems are 
illustrated and neither uses mainframe hardware in the generally accepted sense of the 
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term. The first system illustrated is an IBM Multiprise 3000 system (MP3000). which 
IBM withdrew from marketing as this book was written. It was the smallest S/390 system 
produced in recent years. The MP3000 has one or two S/390 processors plus a SAP 
processor. It also has internal disk drives that can be configured to operate as normal IBM 
3390 disk drives. A minimal internal tape drive is normally used for software installation. 
The MP3000 can have a substantial number of ESCON or parallel channels for 
connection to traditional external I/O devices. 
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The MP3000 is completely compatible with S/390 mainframes, but lacks later zSeries 
features. It can run early versions of z/OS and all prior versions of the operating system. 
It is typically used with z/VM or VSE operating systems. (These operating systems are 
briefly described in Appendix E, “Other mainframe operating systems’’.) 
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Figure 22-12 Very Small Mainframe Configurations 





The FLEX-ES system has no mainframe hardware. It is based on a personal computer 
(running Linux or UNIX) and uses software to emulate S/390 or zSeries systems. Special 
PCI channel adapters may be used to connect to selected mainframe I/O devices. The 
personal computer running FLEX-ES can have substantial internal disks (typically in a 
RAID array) for emulating IBM 3390 disk drives. The FLEX-ES emulator can be used to 
run z/OS and other mainframe operating systems. 


Both these systems lack some features found in “real” mainframes. Nevertheless both are 


capable of doing quality work. Typical application software cannot distinguish these 
systems from real mainframes. In fact, these are considered mainframes because their 
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operating systems, their middleware, their applications, and their style of usage is the 
same as larger mainframes. The MP3000 can be configured with LPARs and might run 
both test and production systems. FLEX-ES does not provide LPARs, but can accomplish 
much the same thing by running multiple copies of FLEX-ES. 


A key attraction of these systems is that they can be a “mainframe in a box.” In many 
cases no external traditional I/O devices are needed. This greatly reduces the entry-level 
price for a mainframe system. 


22.8.2 Medium Single System 


Figure 22-13 outlines a modest mainframe system and indicates the typical external 
elements needed. The particular system shown is an IBM z890 system with two recent 
external disk controllers, a number of tape drives, printers, LAN attachments, and 
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Figure 22-13 Medium Mainframe Configuration 


This is a somewhat idealistic configuration in that no older devices are involved. The 
systems outlined here might have a number of LPARs active, for example: 


> A production z/OS system running interactive applications 
> <A second production z/OS devoted to major batch applications. (These could also be 
run in the first LPAR, but some installations prefer a separate LPAR for management 


purposes.) 
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> A test z/OS version for testing new software releases, new application, and so forth. 
> One or several Linux partitions, perhaps running web-related applications. 


The disk controllers in the figure contain a large number of commodity drives running in 
multiple RAID configurations. The control unit transforms their interfaces to appear as 
standard IBM 3390 disk drives, which is the most common disk appearance for 
mainframes. These disk control units have multiple channel interfaces and can all operate 
in parallel. 


22.8.3 Larger System 
2990, z/OS, Linux, z/VM, Multiple Sharks, old DASD, directors, 3745, lans, consoles 


Figure 22-14 on page 22-25 illustrates a larger mainframe, although this is still a modest 
configuration when compared to a /arge mainframe installation. This example is typical 
in that both older and newer mainframes are present, along with channel switches 
allowing all systems to access most I/O devices. Likewise new and older disk controllers 
(and devices) and tape controllers (and devices) are present. The total system is in a 
modest Parallel Sysplex configuration. 
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Figure 22-14 Moderately Large Mainframe Configuration 


Briefly, the devices in the figure include: 


> 


vvvvvy 


IBM 3745, a communications controller that is optimized for connection to remote 
terminals, remote controllers, and LANs. A 3745 appears as a control unit to the 
mainframe. 

IBM 3490E tape drives are large units that are outdated in many ways. However they 
handle the most widely-used mainframe-compatible tape cartridges and most 
installations have retained some of these drives. 

A sixth-generation design (G6) 

2990 

Enterprise Storage Server 

ESCON directors 

OSA Expresses to several LANs 

CF (Shown as a separate box, but it might be an LPAR in the z990) 
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22.9 Summary 


22-26 


Understanding the meanings (and confusions) of systems, processors, CPs, and so forth 
is important for your expanding knowledge of mainframe computers. 


The original S/360 architecture based on CPUs, memory, channels, control units, and 
devices, and the way these are addressed, is fundamental to understanding mainframe 
hardware—even though almost every detail of the original design has been changed in 
various ways. The concepts and terminology of the original design still permeate 
mainframe descriptions and designs. 


The ability to partition a large system into multiple smaller systems (LPARs) is now a 
core requirement in practically all mainframe installations. The flexibility of the 
hardware design, allowing any processor (CP) to access and accept interrupts for any 
channel, control unit, and device connected to a given LPAR contributes to the flexibility, 
reliability, and performance of the complete system. The availability of a pool of 
processors (PUs) than can be configured (by IBM) as customer processors (CPs), I/O 
processors (SAPs), dedicated Linux processors (IFLs), dedicated Java-type processors 
(zAAPs), and spare processors is unique to mainframes and, again, provides great 
flexibility in meeting customer requirements. It is unfortunate that some of these 
requirements are based on the cost structures of some mainframe software. 


In addition to the primary processors just mentioned (the PUs, and all there 
characterizations) mainframes have a network of controllers (special microprocessors) 
that control the system as a whole. These controllers are not visible to the operating 
system or application programs. 


Since the early 1970s mainframes have been designed as multiprocessor systems, even 
when only a single processor is installed. All operating system software is designed for 
multiple processors and a system with a single processor is considered a special case of a 
general multiprocessor design. 


The EBCDIC character set is different than the ASCII character set. On a 
character-by-character basis translation between the two character sets is trivial. When 
collating sequences are considered the differences are more significant and converting 
programs from one character set to the other can be trivial or can be quite complex. The 
EBCDIC character set, based on an earlier 6-bit BCD character set, became an 
established standard before the current 8-bit ASCII character set had significant use. 


All the but smallest mainframe installations typically use clustering techniques, although 
they do not normally use the terms cluster or clustering. This can be as simple as a shared 
DASD configuration where manual control or planning is needed to prevent unwanted 
data overlap. More common today are configurations that allow sharing of locking and 
enqueueing controls among all systems. Among other benefits, this automatically 
manages access to data sets so that unwanted concurrent usage does not occur. The most 
sophisticated of the clustering techniques is a Parallel Sysplex. 
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22.10 Discussion questions 


1. 


8. 
9. 


Why does IBM have so many models (or “capacity settings”) in recent mainframe 
machines? 


Why does software pricing seem so complex for mainframes? 


Why does the power needed for a traditional COBOL application not have a linear 
relationship with the power needed for a new Java application? 


Multiprocessor means several processors (and means that these processors are used 
by the operating system and applications). What does multiprogramming mean? 


How integrated is the multiprocessing hardware on your favorite RISC machine? 
Why is converting a program from EBCDIC to ASCII not just a simple recompile? 


What are the differences between loosely coupled systems and tightly coupled 
systems? 


Which is better: an internal battery function in a CEC or an external UPS system? 


Why might it be difficult to isolate (“take offline”) a bank of memory? 


10. What z/OS application changes are needed to work in an LPAR? 


22.11 Demonstration 


1. 


This is an appropriate time to visit a mainframe installation if this can be arranged. 
The range of new, older, and much older systems and devices found in a typical 
installation is usually interesting and illustrates the sense of continuity that is so 
important to the mainframe business. 


If a FLEX-ES system is used for class work, this is a good time to view and explain 
its configuration and usage. 


22.12 Exercises 


i. 


2. 


To display the CPU configuration: 


a. Activate a SDSF session 
b. In the command input field, type /D M=CPU and press enter 
c. Use the ULOG option in SDSF to view the command display result 


To display the page datasets usage: 


a. Inthe command input field, type /D ASM and press enter 
b. Press PF3 to return to previous screens. 
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22.13 Instructor Notes 


Re 22.10 Discussion Questions 


Q2 One thing to note about pricing is that a mainframe is a multiuser system and one of 
the assumptions behind the pricing is that the hardware is driven close to 100% 
utilization for much of the online day. This is rarely true of other hardware platforms. 


Q3 The previous discussion about pricing also means that a user will select a model that 
will run the required workload but with little spare capacity. This means that there needs 
to be a wide choice of models. Capacity-on-Demand upgrades can deal with changes in 
workload requirements. 


Q4 Java is a typical new workload for the mainframe. These applications are usually 
CPU hungry as they have not been tailored to the platform as closly as the COBOL 
programs. Thus the need for extra PUs which will not be charged for on a COBOL 
licence. 


Q14 None unless there are some very unusual requirements 


22.14 More information about RAS 
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Author Comment: This section didn’t fit in the “Intructors Notes” in Chapter 2. | 
borrowed some parts of it for the “Instructor's Notes” in Chapter 1, but most of this is too 


detailed for the earlier portions of this course. | placed it here *for now*....But we might 
also consider using it later in the Advanced Topics course (Wayne). 





Processor RAS 


All the processors (PUs) in a zSeries machine have dual instruction-execution elements 
that operate in parallel. Results are compared internally. This occurs continuously and 
automatically for almost every instruction. If the results do not match the instruction is 
retried. (Another RAS element allows the “before” state of affected registers to be 
recalled.) This is transparent to any software. 


If a processor failure is sustained, the state of the processor (register contents and so 
forth) can be moved into memory (by a separate mechanism that is unlikely to be affected 
by the PU failure) and, at that point, the operating system can dispatch the program on a 
different processor. The application is unaware that the processor failure occurred and 
continues execution. The failed processor is taken offline (by the system controllers) and 
a spare PU (if available) is automatically brought online to replace it. 
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The validity of data on internal processor data paths is checked by Hamming code 
methods (an error control method allowing correction of single bit errors) or something 
similar. The same retry functions or PU transfer mechanisms can be invoked. 


Many mainframe models offer an internal battery option. These batteries can keep the 
CEC (processors, memory, channels, but not I/O devices) operational for several minutes 
after a power failure. This provides time to shut down the system cleanly or to start 
external generators. Many installations prefer to have an external uninterruptable power 
system (UPS) that runs the CEC and all the I/O devices. 


Memory RAS 


Memory RAS designs have changed many times and will probably change more times in 
the future. The current zSeries designs include these factors: 


> A large amount of redundant memory exists in the system and this can replace failing 
memory with little or no disruption. 


> Memory words (the memory alignment and width that is actually fetched or stored) 
are spread across multiple chips with enough bits for self-checking and recovery so 
that the failure of a chip will not cause any data loss or system outage. Spare memory 
is automatically invoked to replace failed memory. 


> Key memory elements (such as storage protection keys) are stored in triplex and, 
after other recovery measures have been taken, a voting process is used to sustain 
operation and isolate unusually complex failures. 


> Sections of cache memory can be disabled, if needed, without disrupting system 
operation. (Less cache memory will impact overall system performance, of course.) 


In principle, individual memory units in the largest systems can be removed and replaced 
while the system is operational. This technique is seldom used. 


Earlier generations of mainframes had less redundant memory available (and less 
sophisticated designs for using it). Many earlier designs assumed the system operators 
could isolate banks of memory so that a bank could be replaced without disrupting 
system operation. This seldom worked because many software problems inhibited the 
ability to isolate a bank of memory without substantial application disruptions. This 
technique, whereby an active bank of memory (a card or other replaceable unit) can be 
taken offline, is generally considered a design of last resort. 


A special comment is warranted for mainframe tape reliability. Mainframe users tend to 
completely trust tape records; it is very unusual to find a situation where duplicate tape 
copies are maintained. Tape records can be reliable on any platform, of course, but the 
mainframe assumption is that all tapes (and mainframe tape drives) are reliable and (for a 
given model type) interchangeable. A tape that can be read on some drives but not other 
drives is so unusual that even experienced, long-time mainframe users may have never 
encountered this situation. 
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Hardware Serviceability 


Current mainframes permit many hardware elements to be replaced without impacting 
system operation. For example, there are duplicate redundant power supplies at many 
levels of the system and any of these can be replaced without disrupting operation. 
Larger machines use three-phase power and are designed to continue operation if a power 
phase is lost. 


Channels are implemented as cards that fit in slots in card cages in the processor box. 
Channel cards may be removed while the system is running. Whether or not this is 
disruptive depends on the nature of the channel and whether multiple paths (from other 
channel cards) exist to the affected control units. Some channel cards contain multiple 
channels and have at least one spare channel interface than can be dynamically altered to 
replace a failing channel on the card. 


Some earlier mainframe models allowed individual processors to be replaced while the 
system is running. (Taking a processor offline is much easier than taking memory 
offline.) Current systems are not designed for this. Smaller and denser chips, and need to 
keep processors, cache, and memory close together for performance, has made it 
impossible to remove individual processors. Instead, these systems include spare 
processors in the system and these automatically replace a failing processor. 


The system controllers, operated through the Hardware Management Console (HMC) or 
Support Element (SE) interfaces, provide many diagnostic functions and most of these 
diagnostics can be used while the system is operational. The control programs for the 
system controllers are known as the Driver. New Driver levels can be installed while a 
system is operational although in rare cases it may be necessary to plan, at a convenient 
time, a system restart to completely activate a new Driver. 


The controller technology has changed many times. This level of hardware is not visible 
to the operating system or applications and there are no compatibility issues if a new 
mainframe model uses new controller technology. The controllers in the zSeries of 
mainframes, at the time of writing, are the Flexible Support Processors (FSPs), although 
the term cage controller is sometimes used as a generic name of these types of devices. 
As mentioned before, there are many ways to diagram a mainframe system. Figure 22-15 
provides another view that empathizes the controllers. 
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Figure 22-15 Controllers in z900 System 


The MCMs (Multiple Chip Module) in this particular system contain up to 12 PUs. The 
system has up to four books, each with an MCM and a portion of the total system 
memory. The DCA modules provide power for various portions of the system. Each 
major portion of the system (books, I/O cages) has two DCA modules (for backup) and 
each DCA has two FSP controllers (for backup). Each FSP is connected to two Ethernet 
hubs and each Ethernet hub is connected to a Support Element. Either Support Element 
can manage the system. Without going into more detail, this figure provides the general 
flavor of one aspect of the hardware RAS design. 


LOGREC 


An operational mainframe system sometimes encounters errors. These may be temporary 
internal hardware errors (such as a memory retry that is successful), I/O errors (such as a 
tape error that is recovered), or software errors (such as a ABENDing application). z/OS 
keeps a log of these occurrences along with other statistical information in a data set 
known as SYS1.LOGREC. (The processor hardware notifies z/OS after a hardware error 
has been automatically resolved. z/OS writes this information in LOGREC.) 


In principle, system maintenance people (IBM and customers) study this data and decide 
on maintenance strategies. For example, a certain tape drive may have more temporary 
errors than other tape drives and should receive preventative maintenance. In practice, 
mainframe reliability has become such that the LOGREC data is often ignored. 


Operating System RAS 


z/OS provides a number of RAS elements, including the following: 
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> Every significant function provided by z/OS is covered by at least one recovery 
routine. If the z/OS function ABENDs for some reason the recovery routine attempts 
to repair the problem and rerun the function. 

> Key portions of the system have redundant data, such as double-threaded lists or base 
data (in different control blocks) that can be used to reconstruct working data 
elements. The recovery routines can use this redundant information to recover from 
an ABEND within system routines. 

> z/OS has an architected set of recovery layers, with standard interfaces. System (or 
independent) middleware use these extensively as part of their own recovery designs. 
Applications can also use these interfaces, if wanted. 

> The system administrators can replace some (but not all) portions of z/OS while it is 
running. Altered control parameters can be activated for many portions of the system 
without disrupting operation. These capabilities are being extended with every 
release of z/OS. 


Fixes 


IBM provides a continuous stream of fixes for z/OS and its associated software products. 
These fixes are known as PTFs. These can be installed individually, as collections, or not 
installed at all. New releases of z/OS and other software products incorporate some, but 
not all, of the PTFs that were created for earlier releases. 


z/OS customers differ greatly in the way these fixes are used. Some never install any 
PTFs unless forced to do so by an unavoidable problem; instead they prefer to install new 
software releases at reasonable intervals. (The concept of a reasonable interval also 
varies greatly.) Other customers install collections of fixes (PUT tapes) that are made 
available approximately every month. Yet others monitor all available fixes and decide 
which ones to apply. (This can be very time consuming.) IBM identifies high priority 
fixes and many customers install these. 


Almost all PTFs are installed with the SMP/E utility program. This utility allows fixes to 
be backed out if needed. It can maintain significant historical information about the status 
of fixes applied, pending, or potentially needed in the future. 


PTF is derived from Product Temporary Fix and PUT is for Product Update Tape. These 
extended names are practically never used. 
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Parallel Sysplex 








Objective: 


In this chapter, you will learn: 


about parallel sysplex 

how parallel sysplex can achieve continuous availability 
about dynamic workload balancing 

about single system image 

about geographically dispersed parallel sysplex 
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23.1 Parallel Sysplex overview 


A sysplex is a collection of z/OS systems that cooperate, using certain hardware and 
software products, to process work. A conventional large computer system also uses 
hardware and software products that cooperate to process work. 


A major difference between a sysplex and a conventional large computer system is the 
improved growth potential and level of availability in a sysplex. The sysplex increases 
the number of processing units and z/OS operating systems that can cooperate, which in 
turn increases the amount of work that can be processed. To facilitate this cooperation, 
new products were developed and old products were enhanced. 


Figure 23-1 shows the visible parts of a sysplex, namely the hardware. It illustrates the 
components of a Parallel Sysplex as implemented in the zSeries architecture. 
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Figure 23-1 Sysplex hardware overview 
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23.2 What is a Parallel Sysplex? 


The zSeries Parallel Sysplex uses innovative multisystem data-sharing technology. It 
allows direct, concurrent read/write access to shared data from all processing nodes (or 
servers) in the configuration without sacrificing performance or data integrity. Each node 
can concurrently cache shared data in local processor memory through hardware-assisted 
cluster-wide serialization and coherency controls. As a result, work requests that are 
associated with a single workload, such as business transactions or data base queries, can 
be dynamically distributed for parallel execution on nodes in the sysplex cluster based on 
available processor capacity. 


Parallel Sysplex technology builds on and extends the strengths of zSeries servers by 
linking up to 32 servers with near linear scalability to create the industry's most powerful 
commercial processing clustered system. Every server in a Parallel Sysplex cluster has 
access to all data resources and every "cloned" application can run on every server. Using 
the zSeries Coupling Technology, the Parallel Sysplex technology provides a "shared 
data" clustering technique that permits multi-system data sharing with high performance 
read/write integrity. 


This "shared data" (as opposed to "shared nothing") approach enables workloads to be 
dynamically balanced across all servers in the Parallel Sysplex cluster. It enables critical 
business applications to take advantage of the aggregate capacity of multiple servers to 
help ensure maximum system throughput and performance during peak processing 
periods. In the event of a hardware or software outage, either planned or unplanned, 
workloads can be dynamically redirected to available servers, thus providing 
near-continuous application availability. 


Another significant and unique advantage of using Parallel Sysplex technology is the 
ability to perform hardware and software maintenance and installation in a 
non-disruptive manner. 


Through data sharing and dynamic workload management, servers can be dynamically 
removed from or added to the cluster, allowing installation and maintenance activities to 
be performed while the remaining systems continue to process work. Furthermore, by 
adhering to the IBM software and hardware coexistence policy, software and/or hardware 
upgrades can be introduced one system at a time. This capability allows customers to roll 
changes through systems at a pace that makes sense for their business. 


The ability to perform rolling hardware and software maintenance in a non-disruptive 
manner allows business to implement critical business function and react to rapid growth 
without affecting customer availability. 


Parallel Sysplex technology is an enabling technology, allowing highly reliable, 
redundant, and robust zSeries technologies to achieve near-continuous availability. A 
properly configured Parallel Sysplex cluster is designed to have no single points of 
failure, for example: 
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> Hardware and software components provide for concurrency to facilitate 
non-disruptive maintenance, like zSeries Capacity Upgrade on Demand that allows 
processing or coupling capacity to be added, one engine at a time, without disruption 
to customer workloads. 


> DASD subsystems employ disk mirroring or RAID technologies to help protect 
against data loss, and exploit technologies to enable point-in-time backup, without the 
need to shut down applications. 


> Networking technologies deliver functions such as VTAM Generic Resources, 
Multi-Node Persistent Sessions, Virtual IP Addressing, and Sysplex Distributor to 
provide fault tolerant network connections. 


> I/O subsystems support multiple I/O paths and dynamic switching to prevent loss of 
data access and improved throughput. 


> z/OS and OS/390 software components allow new software releases to coexist with 
lower levels of those software components to facilitate rolling maintenance. 


> Business applications are "data sharing enabled" and cloned across servers to allow 
workload balancing and to prevent loss of application availability in the event of an 
outage. 


> Operational and recovery processes are fully automated and transparent to users, and 
reduce or eliminate the need for human intervention. 


Parallel Sysplex is a way of managing this multi-system environment, providing such 
benefits as: 


Continuous availability 
Capacity 

Dynamic workload balancing 
Ease of use 

Single system image 
Non-disruptive growth 
Application compatibility 


vvvvvvy 


23.2.1 Continuous availability 


23-4 


Within a Parallel Sysplex cluster it is possible to construct a parallel processing 
environment with no single points of failure. Since all systems in the Parallel Sysplex can 
have concurrent access to all critical applications and data, the loss of a system due to 
either hardware or software failure does not necessitate loss of application availability. 


Peer instances of a failing subsystem executing on remaining healthy system nodes can 
take over recovery responsibility for resources held by the failing instance. Alternatively, 
the failing subsystem can be automatically restarted on still-healthy systems using 
automatic restart capabilities to perform recovery for work in progress at the time of the 
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failure. While the failing subsystem instance is unavailable, new work requests can be 
redirected to other data-sharing instances of the subsystem on other cluster nodes to 

provide continuous application availability across the failure and subsequent recovery. 
This provides the ability to mask planned as well as unplanned outages to the end user. 


Because of the redundancy in the configuration, there is a significant reduction in the 
number of single points of failure. Without a Parallel Sysplex, the loss of a server could 
severely impact the performance of an application, as well as introduce system 
management difficulties in redistributing the workload or reallocating resources until the 
failure is repaired. In an Parallel Sysplex environment, it is possible that the loss of a 
server may be transparent to the application, and the server workload can be redistributed 
automatically within the Parallel Sysplex with little performance degradation. Therefore, 
events that otherwise would seriously impact application availability, such as failures in 
CEC hardware elements or critical operating system components, would, in an parallel 
sysplex environment, have reduced impact. 


Even though they work together and present a single image, the nodes in a Parallel 
Sysplex cluster remain individual systems, making installation, operation and 
maintenance non-disruptive. You can introduce changes, such as software upgrades, one 
system at a time, while the remaining systems continue to process work. This allows you 
to roll changes through your systems at a pace that makes sense for your business. 


23.2.2 Capacity 


The Parallel Sysplex environment can scale near linearly from 2 to 32 systems. This can 
be a mix of any servers that support the Parallel Sysplex environment. The aggregate 
capacity of this configuration meets every processing requirement known today. 


23.2.3 Dynamic workload balancing 


The entire Parallel Sysplex cluster can be viewed as a single logical resource to end users 
and business applications. Just as work can be dynamically distributed across the 
individual processors within a single SMP server, so too can work be directed to any 
node in a Parallel Sysplex cluster having available capacity. This avoids the need to 
partition data or applications among individual nodes in the cluster or to replicate 
databases across multiple servers. 


Workload balancing also permits you to run diverse applications across a Parallel 
Sysplex cluster while maintaining the response levels critical to your business. You select 
the service level agreements required for each workload, and the z/OS Workload 
Manager (WLM), along with subsystems such as CP/SM or IMS, automatically balances 
tasks across all the resources of the Parallel Sysplex cluster to meet your business goals. 
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Whether the work is coming from batch, SNA, TCP/IP, DRDA, or WebSphere MQ 
messages, dynamic session balancing, getting the business requests into the system best 
able to process the transaction provides the performance and flexibility you need to give 
the responsiveness your customers demand, and it is invisible to the users. 


There are several aspects to consider for recovery. First, when a failure occurs, it is 
important to bypass it by automatically redistributing the workload to utilize the 
remaining available resources. Secondly, it is necessary to recover the elements of work 
that were in progress at the time of the failure. Finally, when the failed element is 
repaired, it should be brought back into the configuration as quickly and transparently as 
possible to again start processing the workload. Parallel Sysplex technology enables all 
this to happen. 


Workload distribution 

Once the failing element has been isolated, it is necessary to non-disruptively 
redirect the workload to the remaining available resources in the Parallel Sysplex. 
In the event of failure in the Parallel Sysplex environment, the online transaction 
workload is automatically and quickly redistributed without operator intervention. 


Generic Resource Management 

Generic Resource Management provides the ability to specify to VTAM a common 
network interface. This can be used for CICS TORs, IMS Transaction Manager, TSO, or 
DB2 DDF work. 


One of the features of this support is that, for example, if one of the CICS TORs fails, 
only a subset of the network will be affected. The affected terminals will be able to 
immediately log on again and continue processing after being connected to a different 
TOR. 


23.2.4 Ease of use 
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The Parallel Sysplex solution satisfies a major customer requirement for continuous 
24-hour-a-day, 7-day-a-week availability, while providing techniques for achieving 
simplified Systems Management consistent with this requirement. Some of the features 
of the Parallel Sysplex solution that contribute to increased availability also help to 
eliminate some Systems Management tasks. Examples include: 


> z/OS Workload Manager 
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The Workload Manager, or WLM, provides sysplex-wide workload management 
capabilities based on installation-specified performance goals and the business 
importance of the workloads. The Workload Manager tries to attain the performance 
goals through dynamic resource distribution. WLM provides the Parallel Sysplex 
cluster with the intelligence to determine where work needs to be processed and in 
what priority. The priority is based on the customer's business goals and is managed 
by sysplex technology. 


> Sysplex Failure Manager (SFM) 


The Sysplex Failure Management policy allows the installation to specify failure 
detection intervals and recovery actions to be initiated in the event of the failure of a 
system in the sysplex. 


Without SFM, when one of the systems in the Parallel Sysplex fails, the operator is 
notified and prompted to take some recovery action. The operator may choose to 
partition the non-responding system from the Parallel Sysplex, or to take some action 
to try to recover the system. This period of operator intervention might tie up critical 
system resources required by the remaining active systems. Sysplex Failure Manager 
allows the installation to code a policy to define the recovery actions to be initiated 
when specific types of problems are detected, such as fencing off the failed image 
that prevents access to shared resources, logical partition deactivation, or central 
storage and expanded storage acquisition, to be automatically initiated following 
detection of a Parallel Sysplex failure. 


> Automatic Restart Manager (ARM) 


The Automatic Restart Manager enables fast recovery of the subsystems that might 
hold critical resources at the time of failure. If other instances of the subsystem in the 
Parallel Sysplex need any of these critical resources, fast recovery will make these 
resources available more quickly. Even though automation packages are used today 
to restart the subsystem to resolve such deadlocks, ARM can be activated closer to 
the time of failure. 


The Automatic Restart Manager reduces operator intervention in the following areas: 
— Detection of the failure of a critical job or started task 
— Automatic restart after a started task or job failure 


After an ABEND of a job or started task, the job or started task can be restarted 
with specific conditions, such as overriding the original JCL or specifying job 
dependencies, without relying on the operator. 


— Automatic redistribution of work to an appropriate system following a system 
failure 


This removes the time-consuming step of human evaluation of the most 
appropriate target system for restarting work 


> Cloning and symbolics 
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Cloning refers to replicating the hardware and software configurations across the 
different physical servers in the Parallel Sysplex. That is, an application that is going 
to take advantage of parallel processing might have identical instances running on all 
images in the Parallel Sysplex. The hardware and software supporting these 
applications could also be configured identically on all systems in the Parallel 
Sysplex to reduce the amount of work required to define and support the 
environment. 


The concept of symmetry allows new systems to be easily introduced and enables 
automatic workload distribution in the event of failure or when an individual system 
is scheduled for maintenance. It also significantly reduces the amount of work 
required by the systems programmer in setting up the environment. Symmetry does 
not preclude the need for systems to have unique configuration requirements, such as 
the asymmetric attachment of printers and communications controllers, or 
asymmetric workloads that do not lend themselves to the parallel environment. 


System symbolics are used to help manage cloning. z/OS provides support for the 
substitution values in startup parameters, JCL, system commands, and started tasks. 
These values can be used in parameter and procedure specifications to allow unique 
substitution when dynamically forming a resource name. 


23.2.5 zSeries Parallel Sysplex Resource Sharing 


A number of base z/OS components have discovered that the IBM S/390 Coupling 
Facility shared storage provides an excellent medium for sharing component information 
for the purpose of multi-system resource management. This exploitation, called IBM 
zSeries Resource Sharing, enables sharing of physical resources such as files, tape drives, 
consoles, catalogs, etc. with significant improvements in cost, performance and 
simplified systems management. This is not to be confused with Parallel Sysplex data 
sharing by the database subsystems. zSeries Resource Sharing delivers immediate value 
even for customers who are not leveraging data sharing, through native system 
exploitation delivered with the base z/OS software stack. 


One of the goals of the Parallel Sysplex solution is to provide simplified Systems 
Management by reducing complexity in managing, operating, and servicing a Parallel 
Sysplex, without requiring an increase in the number of support staff and without 
reducing availability. 


23.2.6 Single system image 
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Even though there could be multiple servers and z/OS images in the parallel sysplex and 
a mix of different technologies, it is essential that the collection of systems in the parallel 
sysplex appear as a single entity to the operator, the end user, the database administrator, 
and so on. A single system image ensures reduced complexity from both operational and 
definition perspectives. 
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Regardless of the number of system images and the complexity of the underlying 
hardware, the Parallel Sysplex solution provides for a single system image from several 
perspectives: 


> Data access, allowing dynamic workload balancing and improved availability 


> Dynamic Transaction Routing, providing dynamic workload balancing and improved 
availability 


> End-user interface, allowing logon to a logical network entity 


> Operational interfaces, allowing easier Systems Management 


Single point of control 

It is a requirement that the collection of systems in the Parallel Sysplex can be managed 
from a logical single point of control. The term single point of control means the ability 
to access whatever interfaces are required for the task in question, without reliance on a 
physical piece of hardware. For example, in a Parallel Sysplex of many systems, it is 
necessary to be able to direct commands or operations to any system in the Parallel 
Sysplex, without the necessity for a console or control point to be physically attached to 
every system in the Parallel Sysplex. 


Persistent single system image across failures 

Even though individual hardware elements or entire systems in the parallel sysplex fail, a 
single system image must be maintained. This means that, as with the concept of single 
point of control, the presentation of the single system image is not dependent on a 
specific physical element in the configuration. From the end-user point of view, the 
parallel nature of applications in the Parallel Sysplex environment must be transparent. 
An application should be accessible regardless of which physical z/OS image supports it. 


23.2.7 Compatible change and non-disruptive growth 


One of the prime goals of Parallel Sysplex is continuous availability. Therefore, it is a 
requirement that changes such as new applications, software, or hardware can be 
introduced non-disruptively and that they be able to coexist with current levels. In 
support of compatible change, the hardware and software components of the Parallel 
Sysplex solution will allow the coexistence of two levels, that is, level N and level N+1. 
This means, for example, that no IBM software product will make a change that cannot 
be tolerated by the previous release. 


23.2.8 Applications in a Parallel Sysplex 


A design goal of the Parallel Sysplex clustering is that no application changes be required 
to take advantage of the technology. For the most part, this has held true, although some 
affinities need to be investigated to get the maximum advantage from the configuration. 


Chapter 23. Parallel Sysplex 23-9 


Chapter23 sysplex.fm Draft Document for Review December 3, 2004 3:15 pm 


From the application architects’ point of view, three major points might lead to the 
decision to run an application in a Parallel Sysplex: 


> Technology benefits 


Scalability (even with non-disruptive upgrades), availability, and dynamic workload 
management are tools that enable an architect to meet customer needs in cases where 
the application plays a key role in the customer’s business process. And thanks to the 
multisystem data sharing technology, all processing nodes in a Parallel Sysplex have 
full concurrent read/write access to shared data without any harm to integrity and 
performance. 


> Integration benefits 


Since a lot of applications are historically S/390- and z/OS-based, there are 
performance and maintenance benefits when running new applications on z/OS as 
well, especially if they are connected to existing applications. 


> Infrastructure benefits 
If there is already an existing Parallel Sysplex, it needs very little infrastructure work 
to integrate a new application. In a lot of cases the installation does not need to 
integrate new servers. Instead it can leverage the existing infrastructure and make use 
of the strengths of the existing sysplex. With Geographically Dispersed Parallel 
Sysplex (GDPS)—connecting sysplexes in different locations—it is even possible to 
provide a solution enabled for disaster recovery. 


23.2.9 Geographically Dispersed Parallel Sysplex 
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A Geographically Dispersed Parallel Sysplex (GDPS) is the ultimate Disaster Recovery 
and Continuous Availability solution for a zSeries multi-site enterprise. This solution 
automatically mirrors critical data and efficiently balances workload between the sites. 
GDPS solution also uses automation and Parallel Sysplex technology to help manage 
multi-site databases, processors, network resources and storage subsystem mirroring. 
This technology offers continuous availability, efficient workload management, resource 
management and prompt data recovery for business-critical zSeries applications and 
data. Using GDPS/PPRC the current maximum distance between the two sites is 100km 
(approx 62 miles) of fiber, although there are some other restrictions. This provides a 
synchronous solution which gives a zero loss of data, however there is also GDPS/XRC 
which can be used over extended distances and should provide a recovery point objective 
of less than two minutes. That is that a maximum of two minutes data would need to be 
recovered or is lost. 
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23.3 Summary 


The unique characteristics of Parallel Sysplex can enable you to reduce your total cost of 
computing over prior offerings of comparable function and performance. Sysplex design 
characteristics mean that you can run your business continuously, even when it is 
growing or changing. You can dynamically add and change systems in a sysplex and 
configure them for no single points of failure. 


Through this state-of-the-art cluster technology, the power of multiple z/OS systems can 
be harnessed to work in concert on common workloads. The zSeries Parallel Sysplex 
cluster takes the commercial strengths of the z/OS platform to improved levels of system 
management, competitive price/performance, scalable growth, and continuous 
availability. 


23.4 Discussion Questions 


1. What are the advantages of a parallel sysplex presenting a single image externally. 
Are there any disadvantages ? 
2. Why is continuous availability required in today’s marketplace ? 


3. How would you justify the cost of the “redundant” hardware and the cost of the 
software licences required to build a parallel sysplex ? 


23.5 Demonstrations 


1. Show the shared consoles by issuing the command D C on several systems 


2. Use the ROute command to send a command to one other system then to all the 
systems e.g. RO *OTHER, D IPLINFO RO *ALL, D IPLINFO 


3. Show that WLM has only one policy active across the sysplex - D WLM 


23.6 Instructor notes 


If a parallel sysplex is not available this section aims to give some additional materials 
which may be of use either as examples or in discussion. 
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D XCF,S,ALL 
IXC335I 08.40.18 DISPLAY XCF 579 


SYSTEM DYPE SERIAL EPAR StAvUs. TINE SYSTEM STATUS 
SC47 2084 6GASA 09 10/19/2004 08:40:16 ACTIVE 
SC53 2064 OECB 02 10/19/2004 08:40:14 ACTIVE 
SC55 2084 6GA3A 01 10/19/2004 08:40:14 ACTIVE 
SC69 2084 6A3A OA 10/19/2004 08:40:15 ACTIVE 
SC61 2064 OECB 01 10/19/2004 08:40:16 ACTIVE 
SC50 2064 OECB 03 10/19/2004 08:40:17 ACTIVE 
SC54 2084 6GA3A 02 10/19/2004 08:40:15 ACTIVE 
SC49 2084 6GASA 03 10/19/2004 08:40:14 ACTIVE 
SC42 2064 OECB 05 10/19/2004 08:40:16 ACTIVE 
$C43 2064 OECB 06 10/19/2004 08:40:14 ACTIVE 
SC52 2084 6GA3A Or 10/19/2004 08:40:14 ACTIVE 
5C48 2084 6GASA 08 10/19/2004 08:40:14 ACTIVE 
SC66 2064 OECB O7 10/19/2004 08:40:15 ACTIVE 
SC62 2064 OECB OB 10/19/2004 08:40:14 ACTIVE 
SC67 2064 OECB OD 10/19/2004 08:40:16 ACTIVE 
SC04 2064 GOECB 08 10/19/2004 08:40:17 ACTIVE 


Figure 23-2 Sysplex display 


Figure 23-2 shows a sysplex display with 16 active systems. Each has reported active 
within the last 5 seconds. 
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RO XALL,D IPLINFO 

IEE421I RO XALL,D IPLINFO 710 

SC04 RESPONSES ------------------------- 
IEE254I 09.08.04 IPLINFO DISPLAY 709 
SYSTEM IPLED AT 14.18.51 ON 08/28/2004 
RELEASE z/OS 01.04.00 LICENSE = 2/0S 
USED LOADR2 IN SYSO.IPLPARM ON 3800 
ARCHLVL = 2 MTLSHARE = N 

IEASYM LIST = XX 

IEASYS LIST = (R3,04) (OP) 

IODF DEVICE 3800 

IPL DEVICE 8038 VOLUME ZO4RE1 
S$C42 RESPONSES ------------------------- 
IEE254I 09.08.05 IPLINFO DISPLAY 171 
SYSTEM IPLED AT 19.44.10 ON 10/13/2004 
RELEASE z/OS 01.05.00 LICENSE = 2/08 
USED LOADR2 IN SYSO.IPLPARM ON 3800 
ARCHLVL = 2 MTLSHARE = N 

IEASYM LIST XX 

IEASYS LIST = (R3,42) (OP) 

IODF DEVICE 3800 

IPL DEVICE AE10 VOLUME ZO5RA1 
$C43 RESPONSES ------------------------- 
IEE254I 09.08.05 IPLINFO DISPLAY 965 
SYSTEM IPLED AT 13.51.29 ON 08/28/2004 
RELEASE z/OS 01.04.00 LICENSE = 2/0S 
USED LOADR2 IN SYSO.IPLPARM ON 3800 
ARCHLVL = 2 MTLSHARE = N 


Figure 23-3. D IPLINFO 


Figure 23-3 shows the response to a D IPLINFO command in a sysplex. Note that the 
systems have been IPL’d at different times and are running different releases of z/OS. If 
the display had continued it would show that SC04 and SC43 are both running z/OS 
01.04.00 from volume Z04RE1. It also shows consecutive IPLs of z/OS 1.4 on 28th 
August 2004 for SC43 and SC04. 
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RO xXALL,D WLM 
ITEE421I RO *ALL,D WLM 822 
SC04 FES BONS BS ea laa a aaa 
IWMO25I. 09.34.32 WLM DISPLAY 821 
ACTIVE WORKLOAD MANAGEMENT SERVICE POLICY NAME: SPSTPC 
ACTIVATED: 2004/10/18 AT: 11:19:53 BY: RC53 FROM: SC53 
DESCRIPTION: serv pol for db2 stor proc resid 
RELATED SERVICE DEFINITION NAME: SAP414 


INSTALLED: 2004/10/18 AT: 11:19:33 BY: RC5S3 FROM: SC53 
WLM VERSION LEVEL: LEVELO13 
WLM FUNCTIONALITY LEVEL: LEVELO11 
WLM CDS FORMAT LEVEL: FORMAT 3 


STRUCTURE SYSZWLM_WORKUNIT STATUS: CONNECTED 
STRUCTURE SYSZWLM_OECB2064 STATUS: CONNECTED 
SC42 RESRONSES Sao a ee eee eS ee ES ae 
IWMO25I. 09.34.32 WLM DISPLAY 264 
ACTIVE WORKLOAD MANAGEMENT SERVICE POLICY NAME: SPSTPC 
ACTIVATED: 2004/10/18 AT: 11:19:53 BY: RC5S3 FROM: SC53 
DESCRIPTION: sery pol for db2 stor proc resid 
RELATED SERVICE DEFINITION NAME: SAP414 


INSTALLED: 2004/10/18 AT: 11:19:33 BY: RC5S3 FROM: SC5S3 
WLM VERSION LEVEL: LEVELO13 
WLM FUNCTIONALITY LEVEL: LEVELO11 
WLM CDS FORMAT LEVEL: FORMAT 3 


STRUCTURE SYSZWLM_WORKUNIT STATUS: CONNECTED 
STRUCTURE SYSZWLM_OECB2064 STATUS: CONNECTED 


Figure 23-4 DWLM 
Figure 23-4 shows a display for two of the systems in the sysplex. They can be seen to be 


running the same policy which was installed by a third system at exacactly the same time 
throughout the sysplex. 
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D XCF,PATHIN 
IXC355I 10.32.43 DISPLAY XCF 054 
PATHIN FROM SYSNAME: SC42 
DEVICE (LOCAL/REMOTE): 4B30/5B60 4B38/5B68 
STRNAME: IXC_DEFAULT_1 IXC_DEFAULT_2 
IXC_DEFAULT_3 
PATHIN FROM SYSNAME: SC43 
DEVICE (LOCAL/REMOTE): 4B40/5B60 4B48/5B68 
STRNAME: IXC_DEFAULT_1 IXC_DEFAULT_2 
IXC_DEFAULT_3 
PATHIN FROM SYSNAME: SC47 
DEVICE (LOCAL/REMOTE): 4EBO/SB60 4EB8/5B68 
STRNAME: IXC_DEFAULT_1 IXC_DEFAULT_2 
IXC_DEFAULT_3 
PATHIN FROM SYSNAME: SC48 
DEVICE (LOCAL/REMOTE): 4EA0/SB60 4EA8/5B68 
STRNAME: IXC_DEFAULT_1 IXC_DEFAULT_2 
IXC_DEFAULT_3 


Figure 23-5 D XCF,PATHIN 
Figure 23-5 shows the pathin connections to the current system. There are connection to 
the other systems by both CTC devices and by structures. The structures will normally be 


faster but in the event of a problem with them or the coupling facility, the XCF 
communication will drop back to using the CTC devices so giving resilience. 
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D XCF,STRUCTURE 


IXC359I 10.16.35 DISPLAY XCF 945 

STRNAME ALLOCATION TIME STATUS 
APPC_STR1 09/21/2004 21:41:58 ALLOCATED 
CACHECIC 09/18/2004 08:03:13 ALLOCATED 
CACHECICS 09/18/2004 08:02:56 ALLOCATED 
CICS_CACHE 09/18/2004 08:02:44 ALLOCATED 
ISGLOCK 09/18/2004 O7f:27:51 ALLOCATED 
ISTGENERIC 09/18/2004 07:29:05 ALLOCATED 
ISTMNPS 09/18/2004 07:28:49 ALLOCATED 
IXC_DEFAULT_1 09/18/2004 07:47:38 ALLOCATED 
IXC_DEFAULT_2 08/28/2004 13:15:22 ALLOCATED 
IXC_DEFAULT_3 08/28/2004 13:15:21 ALLOCATED 
SYSTEM_LOGREC 08/28/2004 13:19:05 ALLOCATED 
SYSTEM_OPERLOG 09/18/2004 07:27:56 ALLOCATED 
SYSZWLM_WORKUNIT 09/18/2004 07:29:55 ALLOCATED 
SYSZWLM_OECB2064 08/28/2004 13:25:45 ALLOCATED 
SYSZWLM_GASA2Z084 09/18/2004 14:50:22 ALLOCATED 


Figure 23-6 D XCF.STRUCTURE 


Figure 23-6 is an edited output from the command. The IXC structures used by XCF can 
be seen. Also the SYSZWLM structures for Workload Manager. Note that there is one 
structure for each physical machine. There is a 2064 which is a z900 and a 2084 which is 
a z990 (also known as T-Rex). ISGLOCK is the structure used by the GRS (Global 
Resource Serialization) component to ensure the integrity of data set updates. When used 
via a coupling facility this is known as a GRS Star configuration. ISTGENERIC is the 
VTAM Generic Resources structure which is used to map the external names of 
resources to the names on each LPAR. 
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D M=CPU 
IEE1741I 10.56.53 DISPLAY M 088 
PROCESSOR STATUS 


ID CPU SERIAL 
0 + O80ECB2064 
1 + 180ECB2064 


CPC ND = 002064.1C?’.IBM.02.000000010ECB 
CPC SI 2064.1C7.1BM.02. 9000000000001 0ECB 
CPC ID = 00 

CPC NAME = SCZP8O01 


LP NAME = AOD8 LP ID = 8 
MIF ID = 8 
+ ONLINE —- OFFLINE . DOES NOT EXIST W WLM-MANAGED 


N NOT AVAILABLE 


CPC ND CENTRAL PROCESSING COMPLEX NODE DESCRIPTOR 
CPC SI SYSTEM INFORMATION FROM STSI INSTRUCTION 
CPC ID CENTRAL PROCESSING COMPLEX IDENTIFIER 

CPC NAME CENTRAL PROCESSING COMPLEX NAME 

LP NAME LOGICAL PARTITION NAME 

LP ID LOGICAL PARTITION IDENTIFIER 

MIF ID MULTIPLE IMAGE FACILITY IMAGE IDENTIFIER 


Figure 23-7 DM=CPU 


Figure 23-7 shows the output from a D M=CPU command. The processor type, serial 
number and number of logical processors assigned are shown. 
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DC 
IEE889I 11.06.39 CONSOLE DISPLAY 126 
MSG: CURR=0 LIM=1500 RPLY:CURR=10  LIM=999 SYS=SC04 PFK=00 
CONSOLE LD SSeS s4Sseqo==s- SPECIFICATIONS --------------- 
SYSLOG COND=H AUTH=CMDS NBUF=N/A 
ROUTCDE=ALL 
OPERLOG COND=H AUTH=CMDS NBUF=N/A 
ROUTCDE=ALL 
M28 02 COND=M AUTH=MASTER NBUF=N/A 
9300 AREA=Z MFORM=T,S,J,X 
SC47 DEL=R RTME=1/4 RNUM=28 SEG=28 CON=N 
USE=FC ~=LEVEL=ALL PFKTAB=MCONPFKO 


Figure 23-8 DC 


ROUTCDE=ALL 
LOGON=OPTIONAL 
CMDSYS=SC47 
MSCOPE=x*ALL 

MONI TOR=JOBNAMES 
ALTGRP=MASTER 


Figure 23-8 shows the output from a D C command. The only console attached to the 
sysplex is M28. This is connected to SC47. The display command was entered on SC04. 
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Part 5 


Appendixes 


Note to Author: Optionally, describe the book part here. If you are not using Part files, 

you need to restart the page numbering in the first chapter file of your book: 

> In FrameMaker 6.0: Open .book > select first chapter> Format > 
Document > Numbering > Page “tab” > select First Page # radio 


button and set Page # to 1 > Set 
— Now delete the three Part files (p01, p02 and p03) from your book: 
Open .book > select a part file > Edit > Delete File from Book 





In this part we introduce/provide/describe/discuss... 


© Copyright IBM Corp. 2004. All rights reserved. 


Appendixes.fm Draft Document for Review December 3, 2004 3:15 pm 


z/OS Basics 


Draft Document for Review December 3, 2004 3:15 pm Appd A sample tables.fm 


A 


DB2 sample tables 


Most of the examples in Chapter 14, “Overview of DB2 on z/OS” of this book refer to 
the tables described in this appendix. As a group, the tables include information that 
describes employees and departments and make up a sample application that exemplifies 
most of the features of DB2. 


Department table (DEPT) 


The department table describes each department in the enterprise and identifies its 
manager and the department to which it reports. The table resides in table space 
DSN8D81A.DSN8S881D and is created with: 





CREATE TABLE DSN8810. DEPT 





(DEPTNO CHAR(3) NOT NULL, 
DEPTNAME WVARCHAR(36) NOT NULL, 
MGRNO CHAR (6) ; 
ADMRDEPT CHAR(3) NOT NULL, 
LOCATION CHAR(16) ; 


PRIMARY KEY (DEPTNO) ) 
IN DSN&D81A. DSN8S81D 
CCSID EBCDIC; 
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Because the table is self-referencing, and also is part of a cycle of dependencies, its 
foreign keys must be added later with these statements: 





ALTER TABLE DSN8810.DEPT 


ALTER TABLE DSN8810.DEPT 





FOREIGN KEY RDD (ADMRDEPT) REFERENCES DSN8810. DEPT 
ON DELETE CASCADE; 


FOREIGN KEY RDE (MGRNO) REFERENCES DSN&810. EMP 
ON DELETE SET NULL; 








Content of the department table: 





Column Column Name 
1 DEPTNO 

2 DEPTNAME 

3 MGRNO 

4 ADMRDEPT 

5 LOCATION 





Description 


Department ID, the primary key 


A name describing the general activities of the 


department 


Employee number (EMPNO) of the department 


manager 


ID of the department to which this department 
reports; the department at the highest level reports to 


itself 


The remote location name 








The indexes on the department table: 


Name 

DSN8810.XDEPT1 
DSN8810.XDEPT2 
DSN8810.XDEPT3 
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DEPTNO 
MGRNO 
ADMRDEPT 


Type of Index 
Primary, ascendin 
Ascending 


Ascending 
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The Content of the department table: 





DEPTNO DEPTNAME MGRNO ADMRDEPT | 
A0oo SPIFFY COMPUTER SERVICE 000010 AOO 
DIV. 
Bot PLANNING 000020 AOO 
Co1 INFORMATION CENTER 000030 AOO 
Do1 DEVELOPMENT CENTER sooees AOO 
E01 SUPPORT SERVICES 000050 AOO 
D11 MANUFACTURING SYSTEMS 000060 Dot 
D21 ADMINISTRATION SYSTEMS 000070 Dot 
E11 OPERATIONS 000090 E01 
E21 SOFTWARE SUPPORT 000100 E01 
F22 BRANCH OFFICE F2 2 === E01 
G22 BRANCH OFFICE G2 oo---- E01 
H22 BRANCH OFFICE H2 o----- E01 
122 BRANCH OFFICE |2 sonee- E01 
J22 BRANCH OFFICE J2 www E01 


Relationship to other tables: 
The table is self-referencing: the value of the administering department must be a depart- 
ment ID. The table is a parent table of: 
> The employee table, through a foreign key on column WORKDEPT 


> The project table, through a foreign key on column DEPTNO_.It is a dependent of the 
employee table, through its foreign key on column MGRNO. 


Employee table (EMP) 
The employee table identifies all employees by an employee number and lists basic 
personnel information. The table resides in the partitioned table space 


DSN8D81A.DSN8S81E. Because it has a foreign key referencing DEPT, that table and 
the index on its primary key must be created first. Then EMP is created with: 
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CREATE TABLE DSN8810. EMP 


(EMPNO CHAR (6) NOT NULL, 
FIRSTNME VARCHAR(12) NOT NULL, 
MIDINIT | CHAR(1) NOT NULL, 
LASTNAME WARCHAR(15) NOT NULL, 
WORKDEPT CHAR (3) 

PHONENO = CHAR (4) CONSTRAINT NUMBER CHECK 


(PHONENO >= 'GO00' AND 
PHONENO <= '9999') 
HIREDATE DATE 


JOB CHAR (8) , 
EDLEVEL SMALLINT : 
SEX CHAR (1) , 


BIRTHDATE DATE 
SALARY DECIMAL (9, 2) 
BONUS DECIMAL (9,2) 
COMM DECIMAL (9, 2) 
PRIMARY KEY (EMPNO) 
FOREIGN KEY RED (WORKDEPT) REFERENCES DSN&8810.DEPT 
ON DELETE SET NULL 
EDITPROC DSNSEAE1 
IN DSNS&DB81A. DSNBSB1E 
CCSID EBCDIC; 
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Columns of the employee table: 











Column Name Description 

EMPNO Employee number (the primary key) 
FIRSTNME First name of employee 

MIDINIT Middle initial of employee 
LASTNAME Last name of employee 
WORKDEPT ID of department in which the employee works 
PHONENO Employee telephone number 
HIREDATE Date of hire 

JOB Job held by the employee 
EDLEVEL Number of years of formal education 
SEX Sex of the employee (M or F) 
BIRTHDATE Date of birth 

SALARY Yearly salary in dollars 

BONUS Yearly bonus in dollars 

COMM Yearly commission in dollars 





Indexes of the employee table: 








Name On Column Type of Index 
DSN8810.XEMP1 EMPNO Primary, partitioned, ascending 
DSN8810.XEMP2 WORKDEPT Ascending 








Relationship to other tables: 


The table is a parent table of: 
> The department table, through a foreign key on column MGRNO 


> The project table, through a foreign key on column RESPEMPIIt is a 
dependent of the department table, through its foreign key on column 
WORKDEPT. 
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EBCDIC - ASCII table 




















First half of table: 
Hx Dec E A Hx Dec E A Hx Dec E A Hz Dec E A 
00 00 NUL 20 32 SP 40 64 SP @ 60 96 ' 
O01 O01 21 33 ! 41 65 A 61 97 a 
02 02 22 34 7 42 66 B 62 98 b 
03 03 23 35 # 43 67 Cc 63 99 CS 
04 04 24 36 S 44 68 D 64 100 d 
05 05 25 37 % 45 69 E 65 101 e 
06 06 26 38 & 46 70 F 66 102 £ 
07 O7 27 4639 : 47 71 G 67 103 g 
08 08 28 40 ( 48 72 H 68 104 h 
09 09 29 41 ) 49 73 1 69 105 i 
OA 10 2A 42 7 4K 74 * J 6A 106 | J 
OB 11 2B 43 + 4B 75 . K 6B 107 , +&k 
0c 12 2C 44 4c 76 << Ls 6c 108 %$ 1 
OD 13 2D 45 - 4D 77 ( M 6D 109 — ™m 
OE 14 2E 46 ‘ 4E 78 + N 6E 110 n 
OF 15 2F 47 / 4F 79 | Oo 6F 111 ? o 
10 16 30 48 0 50 80 & P 70 112 Pp 
iil “L7 31 49 il. 51 81 Q 71 113 q 
12 18 32 50 2 52 82 R 72 114 r 
13 #19 Be: “orl. 3 ao 383 S 73° 115 Ss 
14 20 34 52 4 54 84 T 74 116 t 
15: <2 Bo. OS 5 SD 85 U 75 117 u 
16 22 36 54 6 56 86 V 76 118 Vv 
17 23 37 55 7 57 87 W 77° 119 Ww 
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18 24 38 56 8 58 88 Xx 78 120 Xx 
19 25 39. 57 9 59 89 Y 79 121 y 
1A 26 3A 58 : 5A 90 ! Z 7A 122 9: Zz 
1B 27 3B (59 ; 5B 91 S$ [ 7B 123 # { 
1c 28 3C 660 < 5G .92. * S 7C 124 @ | 
1D 29 3D 61 = 5D 93 ) ] 7D 125 ! } 
1E 30 3E 62 > 5E 94 ; * 7B 126 = ~ 
1F 31 3F 63 ? 5F 95 not _ 7F 127 ™ 
Second half of table: 

Hx Dec E A Hx Dec E A Hx Dec E A Hz Dec E A 
80 128 AO 160 cO 192 { BO 224 \ 

81 129 a Al 161 C1 193 A El 225 

82 130 b A2 162 s C2 194 B E2 226 § 

83 131 c A3 163 t C3 195 ¢ E3 227 T 

84 132 ada A4 164 u C4 196 D B4 228 U 

85 133 e A5 165 v C5 197 &£E E5 229 V 

86 134 f£ A6é 166 w C6 198 F E6 230 W 

87 135 g A7 167 x C7 199 G E7 231 xX 

88 136 h A8 168 y C8 200 4H E8 232 Y 

89 137 i AY 169 2z c9 201 I E9 233 2 

8A 138 AA 170 CA 202 EA 234 

8B 139 AB 171 CB 203 EB 235 

8c 140 AC 172 CC 204 EC 236 

8D 141 AD 173 [ CD 205 ED 237 

8E 142 AE 174 CE 206 BE 238 

8F 143 AF 175 CF 207 EF 239 

90 144 BO 176 DO 208 } FO 240 0 

91 145 43 Bl 177 D1 209 J Fl 241 1 

92 146 k B2 178 D2 210 K F2 242 2 
93.147 1 B3 179 D3 211 L F3 243 3 

94 148 m B4 180 D4 212 M F4 244 4 

95 149 n B5 181 D5 213 N F5 245 5 

96 150 o B6 182 D6 214 0O FO 246 6 

97. 151 p B7 183 D7 215 P F7 247 7 

98 152 q B8 184 D8 216 Q F8 248 8 

99 153° B9 185 D9 217 R F9 249 9 

9A 154 BA 186 DA 218 FA 250 

9B 155 BB 187 DB 219 FB 251 

9C 156 BC 188 DC 220 FC 252 

9D 157 BD 189 DD 221 FD 253 

9E 158 BE 190 DE 222 FE 254 

9F 159 BF 191 DF 223 FF 255 
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C 


Utility Programs 


z/OS includes a narrow and somewhat uncertain definition of utility programs. Initially, 
utility programs were those programs documented in the early OS/360 Utilities manual. 
By common acceptance of the MVS user community a few programs have been added to 
this set and several have been removed (by becoming obsolete). There is no specific 
definition of what constitutes a z/OS utility program today, but common usage includes 
only a few z/OS-provided programs as utilities. 


The UNIX community, by contrast, considers many of the standard commands as 
utilities. This includes compilers, back up programs, filters, and many other types of 
programs. To the z/OS community these are applications or programs, but are not 
utilities.' The difference is simply one of terminology but it can be confusing to new 
z/OS users. 


Considering the wide-ranging functions and abilities of z/OS there is an astonishingly 
small number of system-provided utilities. Many small, obvious, and useful functions are 
not provided. This has a produced a large number of customer-written utility programs 
(although most users refrain from naming them utilities) and many of these are widely 
shared by the user community. Independent software vendors also provide many similar 
products (for a fee). 


Most of the basic and system utilities described here are documented in IBM book z/OS 
V1R3.0-V1R6.0 DFSMSdfp Utilities, SC26-7414. This chapter is intended to provide a 


flavor of what is available and to provide simple examples of the most basic functions. 


' The z/OS UNIX use the common UNIX terminology for utilities. 
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Basic Utilities 


IEFBR14 


IEBGENER 


A few utility programs (using the traditional terminology) are widely used in batch jobs. 
These are described in some detail here. 


This program does nothing (except provide a 0 completion code). It is used as a safe 
vehicle to “execute JCL.” The notion of “executing JCL” is considered incorrect 
terminology but it conveys the idea very well. For example, consider the following job: 


//OGDEN1 JOB 1,BILL,MSGCLASS=X 

// EXEC PGM=IEFBR14 

//A DD DSN=OGDEN.LIB.CNTL,DISP=(NEW,CATLG) , VOL=SER=WORKO2, 
// UNIT=3390, SPACE=(CYL, (3,1,25) 

//B DD DSN=OGDEN.OLD.DATA,DISP=(OLD, DELETE) 


This is a useful job although the program that is executed (IEFBR14) does nothing. 
While preparing to run the job the initiator will allocate OGDEN.LIB.CNTL and keep 
the data set when the job ends. It will also delete OGDEN.OLD.DATA at the end of the 
job. The DD names A and B have no meaning and are used because the syntax of a DD 
statement requires a DD name. 


The same functions to create one data set and delete another could be done through ISPF, 
for example, but these actions might be needed as part of a larger sequence of batch jobs. 


Note: The name IEFBR14 is interesting. One IBM group writing early OS/360 code 
used the prefix IEF for all their modules. In assembly language BR means Branch to 
the address in a Register. Branching to the address in general register 14 is the 
standard way to end a program. While not an especially clever name, practically all 
dedicated z/OS users remember it easily. 


IEFBR14 is not a utility, in the sense that it is not included in the Utilities manual. 
However, there is no other practical category for this useful program so we have 
arbitrarily placed it in the utility category. 


The IEBGENER utility copies one sequential data set to another. (Remember that a 
member of a partitioned data set can be used as a sequential data set.) It can also do some 
filtering of the data, change LRECL and BLKSIZE, generate records, and several other 
functions. However, the most common use is to simply copy data sets. A typical job 
could be the following: 


//OGDEN2 JOB 1,BILL,MSGCLASS=X 
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IEBCOPY 


//  PGM=IEBGENER 

//SYSIN DD DUMMY 

//SYSPRINT DD SYSOUT=X 

//SYSUT1 DD DISP=SHR,DSN=BILL.SEQ.DATA 

//SYSUT2 DD DISP=(NEW,CATLG) ,DSN=BILL.COPY.DATA,UNIT=3390, 
// VOL=SER=WORKO2, SPACE=(TRK,3,3)) 


IEBGENER requires four DD statements with the DD names indicated in the example. 
The SYSIN DD is used to read control parameters; for simple uses no control parameters 
are needed and a DD DUMMY can be used. The SYSPRINT statement is for messages 
from IEBGENER. The SYSUT1 statement is for input and the SYSUT2 statement is for 
output. This example reads an existing data set and copies it to a new data set. 


If the output data set is new and if no DCB parameters are specified, IEBGENER copies 
the DCB parameters from the input data set. (The DCB parameters include LRECL, 
RECFM, and BLKSIZE, as described in “Basic record formats” on page 4-4.) 


Another common example is something like the following: 


//OGDEN2 JOB 1,BILL,MSGCLASS=X 

// PGM=IEBGENER 

//SYSIN DD DUMMY 

//SYSPRINT DD SYSOUT=X 

//SYSUT2 DD DISP=OLD,DSN=BILL.TEST.DATA 

//SYSUT1 DD * 
This is in-stream data. It can be as long 
as you like. It appears to an application as 
LRECL=80, RECFM=F, BLKSIZE=80. You would 
want to have the SYSUT2 data set allocated with 
a better blocksize. 

/* 


This example assumes BILL.TEST.DATA has already been created. This job will 
overwrite it with the data in the SYSUT1 input stream. Since the output data set already 
exists IEBGENER will use its existing DCB attributes. 


IEBGENER is the most basic copy or list program supplied with z/OS. It has been 
present since the first release of OS/360. 


This utility is commonly used for several purposes: 


> Copy selected (or all) members from one partitioned data set to another. 
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> Copy a partitioned data set into a unique sequential format known as an unloaded 
partitioned data set. As a sequential data set it can be written on tape, sent by F TPZ or 
manipulated as a simple sequential data set. 

> Read an unloaded partitioned data set (which is a sequential file) and recreate the 
original partitioned data set. Optionally, only selected members might be used. 

> Compress partition data sets (in place) to recover lost space/ 


Most z/OS software products are distributed as unloaded partitioned data sets. The ISPF 
copy options (option 3.3, among others) uses IEBCOPY “under the covers.” Moving a 
PDS or PDSE from one volume to another is easily done with IEBCOPY. If there is a 
need to manipulate partitioned data sets in batch jobs IEBCOPY is probably used. 
Equivalent manipulation under TSO (using ISPF) uses IEBCOPY indirectly. 


A simple IEBCOPY job might be the following: 


//OGDEN5 JOB 1,BILL,MSGCLASS=X 

// EXEC PGM=IEBCOPY 

//SYSPRINT DD SYSOUT=* 

//SYSIN DD DUMMY 

//SYSUT1 DD DISP=SHR,DSN=O0GDEN.LIB.SOURCE 

//SYSUT2 DD DISP=(NEW, KEEP) ,UNIT=TAPE, DSN=OGDENS .SOURCE, 
// VOL=SER=123456 


This job will unload OGDEN.LIB.SOURCE (which we assume is a partitioned data set) 
and write it on tape. (The name TAPE is assumed to be an esoteric name that the local 
installation associates with tape drives.) By default IEBCOPY copies from SYSUT1 to 
SYSUT2. Notice that the data set name on tape is not the same as the data set name used 
as input. (The same name could be used, but there is no requirement to do so.) The 
following job could be used to restore the PDS on another volume: 


//JOE6 JOB 1,JOE,MSGCLASS=X 
// EXEC PGM=IEBCOPY 
//SYSPRINT DD SYSOUT=* 
//SYSIN DD DUMMY 
//SYSUT1 DD DISP=OLD,UNIT=TAPE,DSN=OGDENS.SOURCE, 
VOL=SER=123456 
//SYSUT2 DD DISP=(NEW,CATLG) ,DSN=P390Z.LIB.PGMS, UNIT=3390, 
// SPACE=(TRK, (10,10, 20) ) , VOL=SER=333333 
In this example IEBCOPY will detect that the input data set is an unloaded 
partitioned data set. We required external knowledge to determine that the 
data set would fit in about 10 tracks and should have 20 directory blocks. 
Instead of using DD DUMMY for SYSIN we could this: 
//SYSIN DD * 
COPY OQUTDD=SYSUT2, INDD=SYSUT1 
SELECT MEMBER=(PGM1, PGM2) 
/* 


> The output data set is normally V or VB and there are additional considerations about sending V or VB data 
sets via FTP. 
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IEBDG 


The OUTDD and INDD parameters specify the DD names to be used. In this case we 
simply used the default names but this is not required. The SELECT statement specifies 
the member names to be processed. 


Restoring a partitioned data set from an unloaded copy automatically compresses 
(recovers lost space) the data set. 


The IEBDG utility is used to create records in which fields can be generated with various 
types of data. IEBDG 1s typically used to create test data. A variety of fields and data can 
be generated and the fields can be changed for each record with ripple, wave, shift, roll, 
and other field permutations. IEBDG can accept input data records and overlay specified 
fields in the input with generated data. 


The following is a simple example of IEGDB usage: 


//OGDEN7 JOB 1,BILL,MSGCLASS=X 
// EXEC PGM=IEBDG 
//SYSPRINT DD SYSOUT=* 
//OUT DD DISP=(NEW,CATLG) ,DSN=OGDEN. TEST. DATA, UNIT=3390, 
// VOL=SER=WORKO1, SPACE=(CYL, (10,1)), 
// DCB= (RECFM=FB, LRECL=80, BLKSIZE=8000) 
//SYSIN DD * 
DSD OUTPUT=(OUT) 
FD NAME=FIELD1, LENGTH=30, FORMAT=AL,ACTION=RP 
FD NAME=FIELD2,LENGTH=10,PICTURE=10, 'TEST DATA ' 
FD NAME=FIELD3,LENGTH=10, FORMAT=RA 
CREATE QUANTITY=90000,NAME=(FIELD1,FIELD2,FIELD3) 
END 
/* 


This job creates a new data set, OGDEN.TEST.DATA, with 90,000 records. Each record 
is 80 bytes, as specified in the DCB parameters in the DD statement. The control 
statements specify three fields that occupy the first 50 bytes of each records. By default 
IEBDG fills the remaining bytes with binary zeros. The three fields are: 


> An alphabetic field ((ABCDEF...') 30 bytes long. It is rippled (rotated left one byte) 
after each record is generated. 

> The second field contains 10 bytes with the fixed constant 'TEST DATA '. 

> Third field contains 10 bytes with random binary data. 


The utility can generate more complex patterns but this example is typical of simple 
usage. This example also illustrates an estimation of the amount of disk space needed for 
data: 


> We know that a 3390 track holds about 57 K less whatever space is lost to 
inter-record gaps. 
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> We know the DCB parameters (as specified in the JCL) are LRECL=80, 
BLKSIZE=8000, and RECFM=FB. We do not know why these DCB parameters 
were selected and assume they relate to the program that will use the test data. 

> We can estimate that 6 blocks of 8000 each will probably fit on one track. This is not 
an efficient block size because some track space is probably lost, but it is good 
enough. 

> Each block contains 100 records of 80 bytes each. Each track contains 600 records. 
(There is no space lost within a block of FB records.) 

> Acylinder contains 15 tracks, therefore a cylinder will hold 9000 of these records. 

> Based on this we need 10 cylinders to hold 90,000 records. We specified 10 cylinders 
as the primary allocation space in the JCL, with 1 cylinder as the secondary allocation 
increment. We should not require any secondary allocation, but it provides a safety 
factor. We could have asked for 150 tracks instead of 10 cylinders; the result would 
be the same. 


IDCAMS 


The IDCAMS program is not part of the basic set of z/OS utilities documented in the 
z/OS Utilities manual. The IDCAMS program is primarily used to create and manipulate 
VSAM data sets. It has other functions (such as catalog updates) but it is most closely 
associated with VSAM. It provides many complex functions and whole manuals are 
needed to describe all the functions. The basic IBM manual, at the time of writing, is 
DFSMS Access Method Services for Catalogs (IBM form SG26-7394). 


A typical example of a simple IDCAMS usage is as follows: 


//OGDEN12 JOB 1,BILL,MSGCLASS=X 
//DEL EXEC PGM=IDCAMS 
//SYSPRINT DD SYSOUT=* 
//SYSIN DD * 
DELETE OGDEN.DATA.VSAM CLUSTER 
/* 
//LOAD EXEC PGM=IDCAMS 
//SYSPRINT DD * 
//DATAIN DD DISP=OLD,DSN=OGDEN.SORTOUT 
//SYSIN DD * 

DEFINE CLUSTER (NAME (OGDEN.DATA.VSAM) - 
VOLUMES (WORKOZ) CYLINDERS(1 1) - 
RECORDSIZE (72 100) KEYS(9 8) INDEXED) 

REPRO INFILE(DATAIN) OUTDATASET(OGDEN.DATA.VSAM) ELIMIT (200) 

/* 


This example illustrates a number of points: 


> There are two job steps. The first step deletes the data set that will be created by the 
second step. This is a clean-up function. The data set might not exist at this point and 
the first step will have a completion code indicating the action failed. This is ignored. 
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IEBUPDTE 


> Note that there are no DD statements for the VSAM data set. IDCAMS performs 
dynamic allocation to create the necessary JCL. 

> The second step performs two functions. It first creates a VSAM data set (with the 
DEFINE CLUSTER command) and then loads it from a sequential data set (with the 
REPRO command). The sequential data set does require a DD statement. 

> The DEFINE CLUSTER command is continued over three records. The continuation 
indicators are the same as used for TSO commands. 

> The VSAM data set is on volume WORKO2 and uses | cylinder primary space and 1 
cylinder for secondary allocation. The average record size is 72 bytes and the 
maximum record size is 100 bytes. (VSAM data sets always use variable length 
records.) The primary key (for accessing records in the data set) is 8 bytes long and 
begins at an offset of 9 bytes into each record. 

> Records for loading a VSAM data set this way should be already sorted into key 
order. 

> The ELIMIT parameter specifies the number of error records that REPRO will ignore 
before terminating operation. An error record is usually due to a duplicate key value. 


Many of IDCAMS functions can be entered as TSO commands. For example, DEFINE 
CLUSTER can be used as a TSO command. This is generally not a recommend. These 
commands can be complex and the errors encountered can be complex. Entering the 
IDCAMS commands through a batch job allows the commands and resulting messages to 
be reviewed as often as necessary by using SDSF to view the output. 


Note: Some users pronounce the name of this program as “id cams” (two syllables) 
while others say “I D cams” (three syllables). 


The IEBUPDTE utility is used to create multiple members in a partitioned data set or to 
update records within a member. While it can be used for other types of records most 
usage of IEBUPDTE is to create or maintain JCL procedure libraries or assembler macro 
libraries. Today, this utility is used mostly for program product distributions and 
maintenance. It is seldom used by TSO users. 


A basic example involves adding two JCL procedures to MY.PROCLIB. This action 
could easily be done through ISPF, but if we assume the following job was sent on tape 
then the usefulness is more apparent: 


//OGDEN10 JOB 1,BILL,MSGCLASS=X 

// EXEC PGM=IEBUPDTE 

//SYSPRINT DD SYSOUT=* 

//SYSUT1 DD DISP=OLD,DSN=MY.PROCLIB 
//SYSUT2 DD DISP=OLD,DSN=MY.PROCLIB 
//SYSIN DD DATA 

-/ ADD LIST=ALL,NAME=MYJOB1 
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//STEP1 EXEC=BILLX1 

//PRINT DD SYSOUT=A 

// (more JCL for MYJOB1) 

//SYSUDUMP DD SYSOUT=* (last JCL for MYJOB1) 
afl REPL LIST=ALL,NAME=LASTJOB 

//LIST EXEC PGM=BILLLIST 


// (more JCL for this procedure) 
//* LAST JCL STATEMENT FOR LASTJOB 

aff ENDUP 

/* 


This example requires a few comments: 


> When a library is to be updated then SYSUT1 and SYSUT2 both point to the library. 
(If they point to different libraries, the SYSUT1 library is copied to the SYSUT2 
library and then updated). 

> The SYSIN DD DATA format indicates that the data in the input stream contains // in 
columns one and two. It should not be interpreted as JCL. The end of the input stream 
is indicated by /*. 

> The IEBUPDTE utility uses control statements with ./ in the first two columns. 

> A member named MYJOB1 is added to MY.PROCLIB; this member should not 
already exist in the library. 

> A member named LASTJOB is replaced with new contents. 


The IEBUPDTE utility can also add or replace statements in a member based on the 
sequence numbers in the statements. This is one of the few remaining uses for sequence 
numbers in JCL or source statements. 


Again, we stress that IEBUPDTE is typically used for program distribution and 
maintenance. For example, if a software vendor’s product needs to add 25 JCL 
procedures to a customer’s procedure library they might package the procedures as an 
IEBUPDTE job. One advantage is that all the material is in source format and the 
customer can easily review the contents before running the job. 


System-Oriented Utilities 


IEHLIST 


The programs discussed in this section provide several basic utility functions for system 
administrators and are only briefly described. 


The IEHLIST utility is used to list a partitioned data set directory or a disk volume 
VTOC. It is normally used for VTOC listings and provides bit-level information. 
IEHLIST is not used often in most installations but is needed in the rare cases where a 
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IEHINITT 


IEHPROGM 


ICKDSF 


SUPERZAP 


VTOC is corrupted. It is sometimes used with the SUPERZAP program to patch or fix a 
broken VTOC. 


The IEHINITT utility is used to write standard labels on tapes. It can be used, as needed, 
to label a single tape or it can be used to label large batches of tapes. Many larger z/OS 
installations do not allow unlabeled tapes to be brought into the installation. 


The IEHPROGM utility is almost obsolete. It is used primarily to manage catalogs, 
rename data sets, and delete data sets by a program instead of by JCL actions. It was 
primarily used during system installation or the installation of a major program product. 
These functions may involve dozens (or hundreds) or such catalog and data set actions 
and having commands prepared beforehand (in a batch job with IEHPROGM) is much 
less error prone than more dynamic approaches. Most of the IEHPROGM functions are 
available in IDCAMS and that is now the preferred utility for catalog and data set 
functions. 


The ICKDSF utility is used primarily to initialize disk volumes. As a minimum, this 
involves creating the disk label record and the VTOC. ICKDSF can also scan a volume to 
ensure it is usable, reformat all the tracks, write home addresses and RO records and so 
forth. 


The SUPERZAP program is used to patch VTOCs, executable programs, or almost any 
other disk record. In practice it is mostly used to patch executable programs. It was 
extensively used in earlier days to install minor fixes in programs. 


Consider, for example, a new release of product XXX. The new release may have been 
sent on tape to hundreds or thousands of customers. After shipping all these tapes the 
developers may have discovered a minor bug that could be fixed by changing a few 
instructions. Instead of creating new distribution tapes and shipping them to all the 
customers (a massive and expensive undertaking for a major software product), the 
developers could create a superzap solution and mail/fax/ftp it to their customers. 


SUPERZAP is a bit-level tool and its use is practical where relatively few bits or bytes 
need to be changed. An example of SUPERZAP usage is: 


//OGDEN15 JOB 1,BILL,MSGCLASS=X 
// EXEC PGM=AMASPZAP 


Appendix C. Utility Programs C-9 


Appd C utility programs.fm Draft Document for Review December 3, 2004 3:15 pm 


C-10 


//SYSPRINT DD SYSOUT=* 
//SYSLIB DD DISP=OLD,DSN=OGDEN.LIB. LOAD 
//SYSIN DD * 
NAME QSAM1 
VERIFY 004E 4780 
REP  QO04E 4700 
/* 


A SYSLIB DD statement must point to the data set containing the load module to be 
modified. The NAME control statement identifies the executable module (which is the 
PDS member name) to be altered. The VERIFY statement says to look at offset 0x'004E' 
in the module and verify that it contains 0x'4780'. If the verify is correct then change the 
module to contain 0x'4700' at this same offset. This changes a Branch Equal instruction 
to a No Operation and, we assume, changes the logic of the program. 


We can make a SUPERZAP patch like this because we had an assembly listing of the 
program and could see the exact offset within the module containing the instruction we 
wanted to change. This would be much more difficult without a listing although it has 
been done by reading hexadecimal storage dumps and reconstructing machine language 
operation from the dumps. Note that the format of executable programs on disk is 
complex and is not a simple image of the program when it is loaded into memory. 
(Relocation data, external symbols, and a optimized disk loading format form part of the 
complexity.) SUPERZAP understands this disk format and allows users to zap an 
executable program as if it were a memory image. 


We have discussed SUPERZAP but the program in the example is AMASPZAP. This is 
the current name of the program although it is still widely known as SUPERZAP. 


Note: There is much folklore associated with SUPERZAP. When it first appeared 
many years ago (as an undocumented, under-the table tool by IBM) it had no security 
controls. (In those days there was not much security anywhere else in the operating 
system, so this was not unusual.) A clever user could change anything in the system 
with SUPERZAP; payroll records were usually the example cited. This caused much 
concern from management, auditors, and similar people. 


Installations were required to hide SUPERZAP, keep it offline, disable it, and so forth. 
The status of SUPERZAP was high on the list of security auditors. (This is still true 
today, although the need has long since disappeared.) It is still regarded as a magic 
program by some traditional users.) 


It is possible to construct much more sophisticated zaps than the example shown here 
and these were sometimes regarded almost as an art form. For many years developers 
(at least, those developers working in assembly language) often left patch areas in 
their programs. These were unused areas where someone could later zap in a few 
instructions if a fix needed more bytes than provided by instructions being replaced. 
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Application-Level Utilities 


ADRDSSU 


SMP/E 


There are many application programs that could be considered as utilities. We briefly 
describe a few of the very common ones here. These are more complex to use than the 
basic programs above and we do not include usage examples here. 


This program is the primary disk dump and disk restore program provided with z/OS. It is 
capable of filtering and selecting which data sets to dump or restore, but it is used 
primarily as a full disk dump program. The purpose of dumping a disk is usually to 
provide a backup of the contents that can be restored, if needed. A common occurrence is 
to dump complete volumes but restore only a specific data set that was accidently 
destroyed. 


A backup is usually written to tape, but can be written to a disk data set. A disk can be 
dumped track-by-track (known as a physical dump) or data set-by-data set (known as a 
logical dump). When a logical dump is restore multiple data set extents may be combined 
into a single extent, partitioned data sets are compressed, and free space is all in a single 
extent. 


This program is used by the systems programmers (administrators) to install software 
products, updates, and fixes. Using SMP/E is one of the most complex functions 
associated with maintaining z/OS software. Figure C-1 on page C-12 illustrates the 
general flow when using SMP/E to apply a fix to z/OS. (Such fixes for z/OS software are 
known as PTFs, for Product Temporary Fix.) 
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Figure C-1 SMP/E Overview for Fixes 


SMP/E works with three levels of libraries: 


> A receive-level library that is a holding area. This library is known as the PTS (PTF 
Temporary Storage) and is in the GLOBAL zone. 

> Operational or target libraries. These are the working libraries used by z/OS and 
various software products while they are installed for use. 

> Distribution libraries or DLIBs. These contain a master copy of all the modules in the 
operational libraries. The DLIBs are not used for execution. 


Each set of libraries has a CSI (Consolidate Software Index), which is a VSAM data set 
containing data about all the modules in the set. In principle, it is possible to rebuild any 
operational z/OS module from the DLIBs. The CSI contains all the binder (linkage 
editor) control statements needed to rebuild an operational module from submodules in 
the DLIBs. (This is a simplistic description of a complex set of functions and should be 
regarded as such.) 


The SMP/E RECEIVE command is used to accept modules (or submodules of a larger 
module) that are fixes for distributed products. The RECEIVEd module is placed in the 
PTS. The APPLY CHECK command is used to determine if the fix can be cleanly applied 
to the operational module. (This may involve relinking/rebinding many submodules.) If 
these checks are positive, the APPLY command is used to install the fix in the operational 
libraries. The installation would then use the fixed module and determine if it is 
acceptable. If it is not acceptable, a RESTORE command can rebuild the original module 
from material in the DLIBs. If the fix is acceptable (and it make take months to determine 
this) an ACCEPT command integrates the fix module into the DLIBs. After this is done 
the fix can no longer be backed out of the system (except by restoring old backup tapes, 
perhaps). Future fixes can then be built on top of this fix in the DLIBs. A REJECT 
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HCD 


command is used to discard a fix from the global area; this might be done if someone 
decides the fix will never be used. 


SMP/E control statements can verify the status of previous and concurrent fixes, the 
existence of a product and its release level, and many other factors. 


z/OS and practically all z/OS software products from IBM are installed using SMP/E. 
Most independent software vendor products are installed by using SMP/E. Many z/OS 
installations will not purchase any software that is not installed with SMP/E. 


Each product can have its own global, target, and DLIB libraries or many products can be 
placed in the same set of global, target, and DLIB libraries. SMP/E is included with all 
z/OS systems. 


SMP/E usage can be quite complex and SMP/E usage skills are a primary prerequisite for 
a z/OS systems programmer. The DLIBs for a product (including z/OS) tend to be as 
large as the operational libraries. In a sense, almost all the software for z/OS and most 
associated software products is present twice on disk; once for the operational libraries 
and once for the distribution libraries. 


In earlier days, when disks were smaller and more expensive, some installations did not 
keep their DLIBs online. In principle, they are needed only when a fix or new product is 
installed and they could occupy a number of disk drives. Smaller installations might 
dump the DLIB volumes onto tape and restore them (to scratch disks) only when needed. 
In even earlier days the use of SMP/E was considered optional and some installations did 
not maintain their DLIBs. In today’s systems the DLIBs are required for most practical 
purposes and are usually available online. 


This program consists of a large set of ISPF panels, using ISPF as a dialog manager, plus 
several executable modules. HCD is used for several purposes: 


> Using input from the ISPF panels, it builds a special VSAM data set that defines the 
I/O configuration available to z/OS. The data set is known as an IODF. When z/OS is 
started an IODF must be specified. Every I/O device used by z/OS must be defined in 
the IODF. 

> Using approximately the same input from the ISPF panels, HCD builds an I/O 
definition for the complete mainframe machine and sends it to the controller section 
of the mainframe. This definition also specifies the existence of LPARs and other 
system-wide parameters. This is known as an IOCDS (I/O Configuration Data Set). 
The IOCDS is discussed in more detail in Chapter 22, “Hardware systems and 
LPARs” . 

> It can be used to create a new IODF from an existing IODF and dynamically activate 
the new version. 
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An IODF and IOCDS may contain definitions for I/O devices that do not exist or are not 
currently attached. It need not contain definitions for all I/O devices, although the 
system (for the IOCDS) or z/OS (for an IODF) cannot use a device that is not defined. 
HCD usage is a specialized skill needed by only a few systems programmers. It is 
included with all z/OS systems. 


RMF (Resource Measurement Facility) is an optional IBM program product used to 
measure various aspects of system performance. Different RMF modules provide 
long-term statistical gathering, instantaneous data, long-term reporting, batch-type 
reports, TSO-oriented reports, and so forth. The hardware I/O system maintains 
statistical counters about queueing time for each I/O device, amount of activity per 
device, and other low-level information. RMF accesses these hardware counters and 
includes them in its reports. 


Non-IBM Utilities 


Many independent software vendors produce programs for z/OS. Some these can be 
categorized as utilities; of these, some compete with IBM utilities while many others 
provide functions not included with the IBM-provided utilities. 


Summary 


C-14 


The notion of what is a utility program is not well defined for z/OS, but the concept is not 
nearly as wide as for UNIX or Linux. 


IBM provides a few very basic utility programs. These are batch programs (although they 
can be used in the TSO foreground with appropriate ALLOC commands) and they tend 
to have similar JCL requirements. These include DD statements for SYSPRINT, SYSIN, 
SYSUT1, SYSUT2. Most z/OS users are familiar with IEFBR14, IEBGENER, and 
IEBCOPY. VSAM users must be familiar with IDCAMS. 


SMP/E, ADRDSSU, HCD, and RMF are typically used only by systems programmers 
and other administrators and are very seldom used by anyone else. SMP/E and HCD are 
vital for zSeries and z/OS operation. ARDRSSU and RMF are optional and there are 
non-IBM products that compete with these utilities. 


SUPERZAP (whose actual name has changed a number of times) can be used to patch 
disk records. It understands the format of executable modules in PDS libraries and this is 
needed for its most common use in applying patches to such executable modules. 
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SUPERZAP is not often used for system maintenance now, whereas its use was more 
common in earlier versions of the system. 


Discussion Questions 


1. 


A software vendor could distribute a JCL procedure library as an IEBUPDTE job or 
an IEBCOPY unloaded data set. What are the advantages of each? 


IEBUPDTE can merge new statements into a data set (or PDS member) based on 
sequence numbers. When might this be useful? 


Why is the C/C++ compiler not considered a utility? 


What are some “obvious” utility functions not included in our descriptions? Consider, 
for example, a tape map program. Is there a problem in defining what constitutes a 
utility? 

If class permits, a fuller discussion of SMP/E may be interesting. This could include 
the following: 


— Elements of distributions: functions, dependent functions, source distribution, 
CSECTs, modules, combinations of modules, linkage editor control statements. 

— PTFs and APARs, including PTF control statements for prereqs, coreqs, reqs, 
sups, and other oddities of SMP/E controls. 


Exercises and Demonstrations 


The following exercises provide more practice with batch jobs. It may be necessary to 
consult the IBM Utilities manual or other manuals for some of the jobs. 


IEHLIST 


TSO users seldom need the IEHLIST utility. However, it is instructive to use it once and 
to observe the detailed information provided from a VTOC. For this exercise we want to 
use IEHLIST (in its normal mode as a batch job) to examine the VTOC on WORKO2. 
This will require a job something like this: 


//P390ZA JOB 1,BILL,MSGCLASS=X 
// EXEC PGM=IEHLIST 
//SYSPRINT DD SYSOUT=* 
//SYSUT1 DD DISP=O0LD,VOL=SER=WORKO2,UNIT=3390 
//SYSIN DD * 
control statements 
/* 


Consult the IBM Utility manual to complete this job. Most users simply look at the 
examples in the manual. If one of the examples matches our requirements, we simply 
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adapt that material. If none of the examples are close to our needs, we then study the text 
of the manual. 


Note that no data set name is present in the DD statement. This is an unusual situation 
that occurs with only a few special programs. 


CSIs in system 

We only briefly touch SMP/E in this chapter, primarily to emphasize that it exists and is 
important to z/OS installations (but usually not important to most TSO users). Simply to 
demonstrate their presence in our system we want to find the number of CSIs present. 


A fact not mentioned in the text is that, by convention, CSI data set names have a 
low-level qualifier (LLQ) of CSI. We can use ISPF option 3.4 to list all data sets with a 
LLQ of CSI. (As a reminder, this is one of the few uses of wild cards in TSO or 
traditional z/OS.) 


Dump disk to tape 
Use ADRDSSU to back up WORKO2 to tape. Use control statements to allow open data 
sets to be backed up. The following JCL could be used: 


//IBMUSERA JOB 1,BILL,MSGCLASS=X 

// EXEC PGM=ADRDSSU 

//SYSPRINT DD SYSOUT=* 

//DISK DD DISP=OLD,UNIT=3390, VOL=SER=WORKO2 

//TAPE DD DISP=(NEW, KEEP) ,UNIT=560, VOL=SER=111111, 

// DSN=BACKUP..WORKO2 

//SYSIN DD * 

DUMP DATASET(INCLUDE(**)) LOGINDDNAME(DISK) - 
OUTDDNAME(TAPE) TOLERATE(ENQFAILURE) WAIT(0,0) 

/* 


This exercise may not be practical if a tape drive is not available. This example produces 
a logical dump of the data sets on the volume and ignores ENQ failures (that is, if another 
job is using a data set). 


Construct a SUPERZAP 


Look at assembly listing of the QSAM1 exercise. Construct a SUPERZAP program to 
change the logic to test for a blank character instead of the letter B. A blank character is 
x'40' in EBCDIC. Assume executable module QSAM1 is in library P390Z.LIB.LOAD. 
(We do not have QSAM1 in a load module library so we cannot try the zap.) 
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Z/OS—UNIX table 


What would we find if we compared z/OS and UNIX? In many cases, we’d find that 
quite a few concepts would be mutually understandable to users of either operating 
system, despite the differences in terminology. 


For experienced UNIX users, Table D-1 provides a mapping of familiar computing terms 
and concepts. 


Table D-1 Mapping UNIX terms and concepts to z/OS 


Start the operating system IPL (initial program load) the 
system. 


Virtual storage given to each | Users get whatever virtual Users each get an address 
user of the system storage they need to space, a range of addresses 


reference, within the limits of | extending to 2 gigabytes of 

the hardware and the virtual storage (though some 

operating system. of this storage contains 
system code that is common 
for all users). 
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Data format Byte orientation; Record orientation; often an 
organization of the data is 80-byte record, reflecting the 
provided by the application. traditional punched card 

image. 


System configuration data The /etc file system controls Parameters in parmlib control 
characteristics. how the system IPLs and how 
address spaces behave. 


Scripting languages Shell scripts, Perl, awk, and CLISTS (command lists) and 
other languages REXX execs 


Smallest element that A thread. The kernel supports | A task. The z/OS base control 
performs work multiple threads. program (BCP) supports 
multiple tasks. 


A long-running unit of work A daemon. A started task or a 
long-running job 


Order in which the system Programs are loaded from the | The system searches the 
searches for programs to run. | file system according to the following libraries for the 
user’s PATH environmental program to be loaded: 
variable (a list of directories TASKLIB, STEPLIB, 
to be searched). JOBLIB, LPALST and 
LNKLST. 


Using the system Users login to systems and Users log on to the system 
interactively execute shell sessions in the through TSO/E and its 
shell environment. They can | panel-driven interface, ISPF. 
issue the rlogin or telnet A userid can have one only 
commands to connect to the logon session active at a time. 
system. Each user can have 
many login sessions open at 
once. 


Editing data or code Many editors exist, suchas vi, | ISPF editor 
ed, sed, and emacs 


Specifying a source and stdin and stdout SYSIN and SYSOUT 
destination for input and 
output data 


Managing programs The ps shell command allows | SDSF allows users to view 
users to view processes and and terminate their jobs. 
threads, and kill jobs through 
the kill command. 
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Other mainframe operating 
systems 


Besides z/OS, several other operating systems are available for mainframes. This 
appendix provides a brief description of other popular mainframe operating systems and 
their common uses. As we’ve learned, mainframe operating systems are sophisticated 
products and each could justify a separate book. This appendix is intended only as an 
overview. 


It is important to identify the operating systems used with mainframes since they have 
substantially different characteristics and purposes. A given mainframe may use multiple 
operating systems. For example, the use of z/OS, z/VM, and Linux on the same 
mainframe is common. 


Besides z/OS, three other operating systems dominate mainframe usage. These are 
z/VM, VSE, and Linux. A fifth, TPF, is important in special situtions. Brief descriptions 
of these operating systems are provided here 


z/VM is an unusual operating system. In its most basic implementation it provides no 
end-user facilities at all.! Instead it provides virtual machines and z/VM is an instance of 
a hypervisor. A virtual machine includes a processor(s), memory, disk drives, LAN 
interfaces, and so forth. The virtual processor and memory are derived from the real 
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system processor and memory. The disk drives, LAN interfaces, and other I/O devices 
might be complete “real” devices or might be virtual devices that are portions of a real 
device. z/VM makes such portions appear to be separate real devices. 


Other operating systems, known as guest systems, run in the virtual machines created by 
z/VM. For example, z/OS, VSE, and various Linux implementations can run under z/VM 
and these are generally unaware that they are not running in a “real” machine. Another 
operating system is provided as part of z/VM. This is the Conversational Monitor System 
or CMS. CMS is a unique single-user operating system. If multiple z/VM users are 
working with CMS then each user has his own copy of CMS.” CMS runs only under 
z/VM; it cannot be IPLed directly in an LPAR. 


z/VM runs on a basic mainframe (older models) or in an LPAR, like any other operating 
system. An installation might, for example, elect to run some z/OS systems under z/VM 
(all in the same LPAR) and other z/OS systems each in their own LPAR, as illustrated in 
Figure E-1. It is possible to run z/VM under z/VM. Systems running under z/VM are 
known as second-level systems. If z/OS is running under z/VM it is a second-level z/OS. 
While not commonly done, a z/VM running under z/VM running under z/VM would be a 
third-level z/VM. 





zSeries Mainframe z/VM virtual machines 


LPAR 1 AF LPAR 3 





z/OS z/OS 

















zSeries Control, channels, and I/O Subsystem 





1/O Devices 











Figure E-1 2/VM and LPARs 


Figure E-1 roughly illustrates a mainframe with four LPARs. Three z/OS systems are 
running; two in their own LPARs and one under z/VM. Two Linux systems are also 
running, one in its own LPAR and one under z/VM. Two CMS users are shown. A more 
realistic z/VM example might have dozens or hundreds of CMS users and more Linux 
virtual machines. (Since each CMS virtual machine runs a single user we often use CMS 


' There are obviously minor exceptions to this statement. A basic user interface is needed for z/VM 
administration. 

2 Asa practical manner, a single copy of CMS is in z/VM virtual memory but each user appears to have his 
own copy. 
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user and CMS system as synonyms.) We could run multiple z/VM systems in multiple 
LPARs, although this is not illustrated. 


z/VM implementation is conceptually simple, but the details can be complex. Interesting 
details include the following: 


> 


z/VM creates a virtual memory address space for each virtual machine and manages 
the paging needed for this virtual memory. (z/VM typically has dedicated disk 
volumes for paging.) This z/VM virtual memory appears as real memory to the 
virtual machine. For example, z/VM might create 512 MB virtual memory for a 
virtual machine that runs z/OS.? This 512 MB appears as real memory to z/OS, and 
z/OS then creates its own virtual memory address spaces in its “real” memory. This 
results in two independent levels of virtual memory implementation. Today’s 
mainframes have special assistance facilities to handle this situation efficiently. 


The mainframe illustrated in Figure E-1 on page E-2 might have a single processor. 
The mainframe internal controls (the PR/SM facility) share this single processor 
among the LPARs, each of which appears to have its own processor. z/VM then 
shares its processor (which is a fraction of the single real processor) among all its 
virtual machines, each of which appears to have its own processor. z/VM can, in fact, 
provide more virtual processors for a virtual machine than there are real processors in 
the system. In practice, today’s mainframes usually have more than one processor but 
this description emphasizes what can be done. 


The z/VM administrator can assign complete disk drives for a given virtual machine 
and this is commonly done for z/OS volumes. The administrator can also divide a 
disk into many minidisks and provide these for virtual machines. This is commonly 
done for CMS users and Linux systems run under z/VM. A real 3390-3 disk drive, for 
example, has 3339 usable cylinders for data. This can be divided into many 
minidisks, typically with 10 to perhaps 50 cylinders each. Each minidisk appears as a 
complete, separate disk drive (with a small number of cylinders) to a virtual machine. 


Full disk formats can usually be shared among VSE, z/VM guests, and z/OS. 
Minidisks are usable only under z/VM; a minidisk containing z/OS data cannot be 
used by z/OS running native on another system or in an LPAR. Minidisks used by 
CMS are in a unique format that is not used by other operating systems. 


z/VM provides several interconnection services, including virtual LANs, to allow 
virtual machines to communicate with each other. 


z/VM can connect these virtual LANs to one or more “real” LAN interfaces for 
connection to external LANs. There are a number of ways to do this and z/VM 
performs a transparent LAN router function in some cases. 


The additional overhead of running, for example z/OS, under z/VM is small. This is 
partly due to assist instructions provided in zSeries hardware for the purpose of 
minimizing z/VM overhead. 


3 The z/VM administrator specifies the memory size of each virtual machine. 
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z/VM is used for a number of reasons, including the following: 


> Itis convenient for testing other operating systems. For example, the z/VM user can 
IPL the operating system under test. If testing was in an LPAR (without z/VM) the 
system operators would need to be involved in order to IPL an operating system. 


> It provides a convenient interactive terminal interface for VSE installations. The 
combination of VSE for batch and transaction processing and z/VM for interactive 
terminal use (for development, system management, and so forth) is convenient for 
many users of smaller mainframes. 


> AnLPAR provides a fixed amount of memory, as determined when the system 
administrators divide the system memory among the LPARs they define. The 
memory in an LPAR must be large enough for the purposes of the operating system 
running in the LPAR. This “large enough” may be much larger than needed during 
most of the operational period. There is no way to quickly shift real memory from one 
LPAR to another as system workloads change. z/VM uses whatever real memory it 
has (in its partition) to create virtual memory in which to run its guest operating 
systems. The total virtual memory for all the guests is normally larger than the real 
memory available to z/VM and z/VM uses paging techniques to dynamically shift 
real memory as needed. 


Whether to run an operating system in its own LPAR or under z/VM (assuming z/VM is 
available) is sometimes not a clearcut decision and can cause much debate among 
mainframe workers. 


z/VM includes an OPERATOR session than can be accessed (with the proper password) 
from any user terminal. This session receives status information and can perform various 
hardware device management functions. However, the operator function in z/VM is not 
as fundamental as in VSE or z/OS. z/VM systems often run with the operator session 
disconnected from any terminal. 


The most recent versions of z/VM can IPL and operate from Storage Area Network 
(SAN) disk drives. (It also continues to use the traditional CKD drives.) As of z/VM 5.1, 
z/VM has its own SCSI driver and can therefore present SCSI disks to guests as ordinary 
FBA disks. The SAN drives are not relevant for z/OS or VSE guests under z/VM, but 
they can be used by CMS users and Linux guests. SAN drives are connected through a 
Fibre Channel Protocol (FCP) network using SCSI protocols. 


z/VM evolved from earlier versions and has undergone a series of name changes. These 
include CP-40, CP-67, VM/370, VM/SP, VM/XA, and VM/ESA. The collective name 
VM is often used when referencing any recent release. 
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VSE 


Compared to z/OS, the VSE operating system provides a smaller, less complex base for 
batch processing and transaction processing. It is most commonly used in smaller 
mainframes. The design and management structure is excellent for running routine 
production workloads consisting of multiple batch jobs (running in parallel) and 
extensive, traditional transaction processing. 


VSE differs from z/OS in a number of ways, including the following: 


> The job control language used to manage batch jobs is simpler and does not provide 
the more extended functions found in z/OS. 

> The supervisor services provided to applications are completely sufficient for 
traditional batch jobs and a transaction processing manager but do not provide the 
many more exotic services provided by z/OS, especially as related to multiple address 
space usage, extended software recovery interfaces, multiple system coupling 
facilities, and dynamic management of system resources. 

> Memory and address space management is build on a simpler model than that of 
z/OS. 

> No general terminal interface is provided for users. 


In practice, most VSE users also have the z/VM operating system and use this as a 
general terminal interface for VSE application development and system management. 


VSE provides many of the facilities that z/OS provides, but usually in a simpler 
implementation. It includes indexed files (the VSAM access method), relational data 
bases‘ (typically IBM’s DB2 product), traditional SNA networking, modem TCP/IP 
connectivity, strong transaction processing functions (normally with IBM’s CICS 
product), and so forth.4 


VSE is controlled from an operator console (an IBM 3270 terminal or a device emulating 
a 3270). The operator can start and stop job processing, hold jobs, control peripheral 
devices, and so forth. An operator terminal is not an end-user terminal. An operator 
cannot do program development or access data from an operator terminal. 


Disk and tape file formats used by VSE are generally compatible with formats used by 
z/OS. In principle, an installation could use a mixture of these operating systems with 
shared data. In practice this is rare. The compatibility of most data eases a migration from 
VSE to z/OS when this is desired. 


VSE systems normally use CKD disk drives, in the same manner as they are used for 
z/OS. 


4 As with other operating system environments, some of these functions are provided by separately priced 
program products. 
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Linux 


This operating system was originally known as DOS and was the first disk-based 
operating system introduced for the S/360 machines. It was seen as a temporary measure 
until OS/360 (the ancestor of z/OS) would be ready. However, many mainframe 
customers liked the simplicity (and small size) of DOS and decided to remain with it 
after OS/360 became available. DOS became known as DOS/VS (when it started using 
virtual storage), then VSE/SP and later VSE/ESA. The name VSE is often used 
collectively to reference any of the more recent versions. 


Several Linux distributions can be used on a mainframe. These distributions are not from 
IBM but their use is supported by IBM. Two generic names are used for these 
distributions: 


> Linux for S/390 (uses 31-bit addressing and 32-bit registers) 
> Linux for z/Series (uses 64-bit addressing and registers). 


Other than the larger registers and addressing range provided with the 64-bit version, the 
Linux characteristics are about the same and can be described as a single entity. The 
phrase Linux on zSeries is used to refer to Linux running on an S/390 or zSeries system, 
when there is no specific need to refer explicitly to either the 31-bit version or the 64-bit 
version. 


We assume students are generally familliar with Linux and we mention only 
characteristics that are relevant for mainframe usage. These include the following: 


> Linux uses traditional CKD disk devices and/or SAN-connected SCSI type devices. 
The CKD disk driver for Linux formats the disks into 4K blocks and, in effect, uses 
them as fixed block devices. Other mainframe operating systems can recognize these 
drives as Linux drives but cannot use the data formats on the drives. That is, there is 
no sharing of data between Linux and other mainframe operating systems. 


> Linux does not use 3270 terminals, while all other mainframe operating systems use 
3270s as their basic terminal architecture.> Linux uses typical ASCII terminals, 
normally connected via telnet. This has the following implications: 


— z/VM provides emulated ASCII typewriter terminal sessions (using a 3270 
terminal). If Linux is started under z/VM then this terminal function is sufficient 
to get Linux started and perform basic control functions. The terminal emulation 
is not sufficient for running vi or similar full-screen ASCII terminal applications. 
In practice the Linux users (and administrators) log into Linux from telnet 
sessions as soon as Linux TCP/IP is available. 


— Linux can be run natively (without z/VM) in an LPAR. Here, the initial Linux 
startup messages are displayed in a window on the mainframe hardware 


> There is a Linux driver for minimal 3270 operation, in very restrictive modes, but this is not commonly used. 
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management console (HMC), which provides very basic typerwriter-like terminal 
emulation. As soon as TCP/IP services are available in Linux, users and 
administrators can log into Linux from telnet sessions. Newer versions of the 
HMC provide a full ASCII terminal emulator window which can be used to 
administer a native Linux installation in situations where full TCP/IP services 
have not started up. 


> Linux has drivers for using the more recent sophisticated mainframe LAN adapters. 
Multiple Linux images, in multiple LPARs, can use the same physical LAN adapter 
as if it were many separate LAN adapters. 


> With the proper setup a Linux system under z/VM may be quickly cloned to make 
another, separate Linux image. The z/VM emulated LAN may be used to connect 
many Linux images together and to provide an external LAN route for them. 
Read-only file systems, such as a typical /usr file system, may be shared by many 
Linux images. 


> Linux fully supports mainframe tape drives that are SAN-connected by FCP 
channels. Linux does not support mainframe tape drives attached by traditional 
channels. 


> Linux on a mainframe operates with the ASCII character set, not the EBCDIC 
character set. The only EBCDIC involved is when writing to character sensitive 
devices such as displays and printers. The Linux drivers for these devices handle the 
character translation. 


The TPF operating system, with the name taken from Transaction Processing Facility, is 
a special purpose system used by a few very large installations. It was once known as the 
Airline Control Program and was used for airline reservation systems. It is still used for 
this purpose and has been extended for other very large reservation systems and similar 
high-volume transaction processing requirements. 


TPF can use multiple mainframes and/or LPARs in a loosely-coupled environment to 
routinely handle thousands of transactions per second while experiencing uninterrupted 
availabilities measured in years. Very large terminal networks, including special-protocol 
networks used by portions of the reservation industry, are common. 


Early versions used applications written to rather limited, special interfaces and written 
in assembly language. Recent versions of TPF have added a high-volume web server, 
application programming in C, standard links to relational databases on z/OS systems, 
and cross-platform application development using z/OS. 
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Versions and releases of operating systems 


Most software products involve new releases of the product and mainframe software is 
no exception. The naming conventions for these releases (using releases in its most 
general sense) is often important when describing mainframe environments. In the IBM 
scheme (which has been adopted by most software vendors) there is a heirarchy of 
product, version, release, and modification levels. 


For example, z/OS evolved from OS/390 and in a generic sense can be considered a later 
release of it. However, in a more formal sense z/OS is a different product than OS/390 or 
MVS. In the case of operating systems and some products the modification level 
nomenclature is not used. Instead a fix level may be used in some cases. 
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Instructor Notes 
Refer to “z/VM” on page E-1 


Customers use the hypervisor capability of z/VM for a number of reasons. One of which 
is to test newer releases of an existing production system, such as z/OS. Under z/VM, one 
can install the latest release of z/OS for testing, while still operating the current 
production release. The newer release might contain functional or corrective upgrades; 
these are tested in parallel while the existing release continues in production. Only when 
the customer is satisfied that the new release meets their expectations, is the new release 
‘cut-over’ and the old release removed. z/VM allows the customer to conduct this 
parallel test with virtually no risk to current operations. 


Another example of the use of z/VM is to have a system identical to the production 
system for exclusive use by the application developers. These programmers can develop 
and test new applications using the same environment as the production system, without 
causing any risk to production operations. In other words, z/VM insulates the production 
system from any potential programming errors. 


As another example, entirely different operating systems can be installed under the 
control of z/VM. Suppose a mid-sized customer has successfully used VSE for years to 
tun its production systems, but has grown to the point that z/OS is now a more attractive, 
functionally richer, system. This customer could add some additional hardware capacity 
and install a version of z/OS under z/VM on the single hardware system. The customer 
could test z/OS while continuing to use VSE to run the production applications under 
z/VM. When satisfied that z/OS provides the expected benefits, the customer could cut 
over to z/OS, and at their leisure, gradually convert the existing VSE applications to 
z/OS. Or, (and this is significant) they could continue to run both VSE and z/OS under 
z/VM and never convert the VSE applications. 


Finally, various Linux implementations can run under z/VM and these are generally 
unaware that they are not running in a “real” machine. 


Performance of virtual machines is good and many production installations operate in 
this mode. If desired, the system programmer could designate a single guest system as a 
‘preferred’ guest which would receive a greater share of the hardware resources (CPU 
cycles). 
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A Little Bit of IBM 
Mainframe History 


This appendix shows the development of the IBM mainframe from 1964 to present. 
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Figure F-1 Timeline 


On April 7, 1964 IBM introduced the System/360, a family of five increasingly powerful 
computers that ran the same operating system and could use the same 44 peripheral 
devices. With S/360 were born the I/O subsystem concept, namely defining processors to 
transfer data between memory and I/O devices, and parallel channels, that are channels to 
transmit data in parallel to I/O devices. 
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Figure F-2 S/360 Model 40 


For the first time, companies could run mission critical applications for business on a 
highly secure platform. In 1968, IBM introduced Customer Information Control System 
(CICS). It allowed workplace personnel to enter, update and retrieve data online. To date, 
CICS remains one of the industry's most popular transaction monitor. In 1969, Apollo 
11's successful landing on the moon was supported by several System 360s, Information 
Management System (IMS) 360 and IBM software. 














Figure F-3 S/370 Model 165 


In the summer of 1970, IBM announced a family of machines with an enhanced 
instruction set, called System/370. These machines became capable of using more than 
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one processor in the same system (initially two) sharing the memory. Through the 1970's 
the machines got bigger and faster and multi-processor systems became common. The 
370 Model 145 was the first computer with fully integrated monolithic memory (circuits 
in which all of the same elements: resistors, capacitors and diodes are fabricated on a 
single slice of silicon) and 128-bit bipolar chips. More than 1,400 microscopic circuit 
elements were etched onto each one-eighth-inch-square chip. Able to run System/360 
programs, thus easing the upgrade burden on customers, the System/370 was also one of 
the first lines of computers to include "virtual memory" technology, a technique 
developed to expand the capabilities of the computer by using space on the hard drive to 
accommodate the memory requirements of software. 


In 1980, it was the introduction of the 3081 processor. The 3081 offered a two-fold 
increase in internal performance from the previous mainframe processor, the 3033. It also 
featured Thermal Conduction Modules that significantly reduce space, cooling and 
power requirements. Around 1982, addresses were extended from 24 bits to 31 bits 
(370XA). In 1984 IBM announced a one-megabit Silicon and Aluminum Metal Oxide 
Semiconductor (SAMOS) chip. Though "mega" means million, the chip actually holds 
1,048,576 bits of information in a space smaller than a child's fingernail. In 1988 
extensions were put in to support multiple address spaces. Still in 1988 using the 
mainframe, customers could deploy the DB2 database beyond "decision support 
systems" and into core transactional processing, driving reductions in CPU costs and 
dramatic improvements in concurrency. In this period IBM introduced the Logical 
Partition concept that allow a mainframe logically partition into several independent 
processors sharing the same hardware. 
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Figure F-4 3081 Processor Complex 
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F-4 


Some industry pundits, however, didn't think the mainframe would survive the early 
1990s. They predict that the rapid growth in personal computers and small servers would 
render "big iron" obsolete. But IBM believed that serious, security-rich, 
industrial-strength computing would always be in demand, hence the System/390. IBM 
sticks with the mainframe, but reinvented it from the inside: infusing it with an entirely 
new technology core and reducing its price. 


It introduced the concept of System Clustering and Data Sharing. IBM announced the 
System/390 Parallel Sysplex which allowed for very high levels of system availability. 
Complementary Metal Oxide Semiconductor (CMOS) based processors were introduced 
into the mainframe environment replacing the bipolar technology and setting the new 
roadmap for modern mainframe technology. CMOS chips required less power than chips 
using just one type of transistor. In the same decade, IBM introduced the parallel channel 
by Enterprise System Connectivity (ESCON) and began the integration of network 
adapter to mainframe, Open System Adapter (OSA). In 1998 IBM introduced a new 
module capable of surpass the 1,000 MIPS barrier, making it one of the world's most 
powerful mainframe. Also in this period, the concept of logical partition was extended to 
support 15 partitions. Capacity Upgrade on Demand (CUoD) debuts on the System/390 
in 1999. CUoD provides extra processors installed as spare capacity that can be "turned 
on" as dictated by business needs. It provides a critical tool that can help companies 
better manage spikes in demand and handle unpredictable changes. Still in 1999 IBM 
introduced the first enterprise server to use IBM's innovative copper chip technology. 
The synergy helps extend customers' ability to handle millions of e-business workload 
transactions and large-scale Enterprise Resource Planning applications. A new concept 
arose in that time, the processors not disruptive, namely, the possibility to increase the 
machines capacity without stopping them. FICON, new fiber optic channel was 
introduced with up to eight times the capacity of ESCON channels. Also In 1999 Linux 
appears on the System/390 for the first time. 

















Figure F-5 S/390 G5 and G6 
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In October of 2000 IBM announced the first generation of IBM current mainframe 
family. IBM also decided to call all eServers, and mainframe became z/Series. 


The z architecture was an extension to ESA/390 and supports 64 bits addressing. 
Dynamic channel management was also introduced, as well as specialized cryptographic 
capability. Mainframe became open and capable of executing Linux; special processors 
(IFLs) have been developed. 


The on demand era plays to the strengths of the IBM eServer z/Series. z900 was launched 
in 2000 and was the first IBM server "designed from the ground up for e-business." The 
latest member of the family, z990 brings enriched functions that are required for the on 
demand data center. 

















Figure F-6 z900 


The current generation of mainframe reaches 9000 MIPS; the increased scalability is 
further supported by the increase in the number of Logical Partitions available from the 
15 LPARs to 30 LPARs. There is still a 256-channel limit per operating system image, 
but z990 can have 1024 channels distributed in 4 Logical Channels Subsystems. In the 
current model are available IFL, processor special for Linux to manager clustering and 
ZAAP to processing JAVA. 


zSeries is based on the 64-bit z/Architecture, which is designed to reduce memory and 
storage bottlenecks and can automatically direct resources to priority workloads through 
Intelligent Resource Director (IRD). IRD is a key feature of the z/Architecture. Together, 
Parallel Sysplex technology and IRD are designed to provide the flexibility and 
responsiveness required by on demand business workloads. 


The z990 provides a multi-book system structure that supports the configuration of one 
to four books. Each book is comprised of a MultiChip Module (MCM), with 12 
processors of which 8 can be configured as standard processors; memory cards, that can 
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support up to 64 GB of memory per book and high performance Self-Timed 
Interconnects. The maximum number of processors available on a z990 is 32. 


To support the highly scalable multibook system design, the Channel SubSystem (CSS) 
has been enhanced with Logical Channel SubSystems (LCSSs) which provides the 
capability to install up to 1024 ESCON channels across three I/O cages. With Spanned 
Channel support, HiperSockets, ICB, ISC-3, OSA-Express and FICON Express can be 
shared across LCSS for additional flexibility. High-speed interconnects for TCP/IP 
communication, known as HiperSockets, let TCP/IP traffic travel among partitions and 
virtual servers at memory speed, rather than network speed. 

















Figure F-7 z990 
The mainframe delivers enriched functions for the on demand operating environment. 


zSeries is the enterprise class e-business server optimized for mixed workload 
integration, high transaction processing, and data serving for the on demand world. 


F-6 z/OS Basics 


Appd G PSWand registers.fm 


G 


Draft Document for Review December 3, 2004 3:15 pm 


Registers and PSW 
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Figure 0-1 Register and PSW 
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The CP provides registers to keep track of the instruction address and the storage location 
of data to be processed. 


The instruction address is found in a hardware register called the Program Status Word 
(PSW). The PSW is used to govern exactly how each instruction is executed. Each CP is 
governed by its own PSW. The PSW contains information that is required for the 
execution of the currently active program. 


Access registers are used to specify in which space (data space or address space) data is 
found 


General registers are used to address data in storage, and also used for holding user data 
Floating point registers are used to hold numeric data (in floating point form). 


Control registers are used by the operating system itself, for example, a reference to 
translation tables. 
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Related publications 


The publications listed in this section are considered particularly suitable for a 
more detailed discussion of the topics covered in this textbook. 


z/OS JCL and Utilities Reference 


> z/OS VIR6.0 MVS JCL Reference, SA22-7597 
> z/OS VIR6.0 MVS JCL User's Guide, SA22-7598 
> z/OS VIR3.0-V1R6.0 DFSMSdfp Utilities, SC26-7414 


z/OS UNIX Reference 


> z/OS UNIX System Services Command Reference, SA22-7802 
> z/OS UNIX System Services User's Guide, SA22-7801 
> z/OS UNIX System Services Planning, GA22-7800 


z/OS Communications Server Reference 


z/OS VIR6 Communications Server Quick Reference, SX75-0124-04 

z/OS VIR6 Communications Server IP Configuration Guide, SC31-8775 
z/OS VIR6 Communications Server IP Configuration Reference, SC31-8776 
z/OS V1R6 Communications Server SNA Operations, SC31-8779 
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Language Reference 
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HLASM General Information, GC26-4943 

HLASM Installation and Customization Guide, SC26-3494 
HLASM Language Reference, SC26-4940 

You can also find these manuals through the web site: 


http: //www-1.ibm.com/servers/eserver/zseries/zos/bkserv/find_shelves.html 


Enterprise COBOL for 2/OS and OS/390 V3R2 Language Reference, 
SC27-1408 


Enterprise COBOL for z/OS and OS/390 V3R2 Programming Guide, 
$C27-1412 


Enterprise PL/I Language Reference, SC27-1460 
Enterprise PL/I for 2/OS V3R3 Programming Guide, SC27-1457 


C/C++ Language Reference, SC09-4764 
C/C++ Programming Guide, SC09-4765 


IBM SDK for z/OS V1.4 Program Directory, Gl11-2822 


2/OS V1R5.0 Language Environment Concepts Guide, SA22-7567 
2/OS V1R5.0 Language Environment Programming Guide, SA22-7561 


The REXX Language, 2nd Ed., Cowlishaw, ZB35-5100 

Procedures Language Reference (Level 1), C26-4358 SAA CPI 
REXxX on zSeries V1R4.0 User's Guide and Reference, SH19-8160 
Creating Java Applications Using NetRexx , SG24-2216 

For more information, refer to the websites: 

http: //www-306.ibm.com/software/awdtools/REXX/1anguage/REXX1inks. html 
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CICS References 


> 


> 


CICS Application Programming Primer, SC33-0674 


CICS Transaction Server for zZ/OS - CICS Resource Definition Online, 
SC34-6228 


CICS Transaction Server for 2/OS - CICS System Definition Guide, 
SC34-6226 


CICS Transaction Server for z/OS - CICS Operations and Utility Guide, 
SC34-6229 


CICS Transaction Server for 2/OS - CICS Application Programming Guide, 
SC34-6231 


CICS Transaction Server for z/OS - CICS System Programming Reference, 
SC34-6233 


CICS Transaction Server for z/OS - CICS Customization Guide, SC34-6227 


CICS Transaction Server for z/OS - CICS Application Programming 
Reference, SC34-6232 


Architecting Web Access to CICS, SG24-5466 (redbook) 


IMS References 


IMS Primer, SG25-5352 

IMS Application Programming: Design Guide, SG27-1287 

IMS Application Programming: Database Manager, SG27-1286 
IMS Application Programming: Transaction Manager, SG27-1289 
IMS Java Guide and Reference, SC27-0832 


Connecting IMS to the World Wide Web, A Practical Guide to IMS 
Connectivity, SG24-2220 


DB2 References 


DB2 UDB for z/OS: Administration Guide,SC18-7413 
DB2 UDB for 2/OS: Application Programming and SQL Guide, SC18-7415 


DB2 UDB for z/OS: Application Programming and Reference for Java™, 
SC18-7414 


DB2 UDB for z/OS: Command Reference, SC18-7416 
DB2 UDB for z/OS: Data Sharing: Planning and Administration, SC 18-7417 
DB2 UDB for z/OS: Installation Guide, GC18-7418 
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> DB2 UDB for z/OS: SQL Reference, SC18-7426 
> DB2 UDB for z/OS: Utility Guide & Reference, SC18-7427 
> Redbook: IBM DB2 Performance Expert for z/OS Version 2, SG24-6867-01 


WebSphere References 


> IBM WebSphere Application Server V5.1 System Management and 
Configuration WebSphere Handbook Series, SG24-6195 


> 2/OS WebSphere Application Server V5 and J2EE 1.3 Security Handbook, 
SG24-6086 


WebSphere MQ References 
> MQSeries Primer, REDP-0021 
> WebSphere MQ Application Programming Guide, SC34-6064 
> WebSphere MQ Bibliography and Glossary, SC34-6113 
> WebSphere MQ System Administration Guide, SC34-6068 
For more information, refer to the websites: 


http://www. ibm.com/software/integration/mqfamily/1ibrary/manualsa/ 


Systems Programming 
> 2/O0S MVS System Data Set Definition, SA22-7629 
> 2/0S MVS Initialization and Tuning Reference, SA22-7592 
> 2/0S MVS Initialization and Tuning Guide, SA22-7591 
> JES2 Initialization and Tuning Guide, SA22-7532 


IBM Redbooks 


For information on ordering these publications, see “How to get IBM Redbooks” 
on page H-6. Note that some of the documents referenced here may be available 
in softcopy only. 


> ABCs of z/OS System Programming - Volume 1 - Introduction to z/OS and 
storage concepts, TSO/E, ISPF, JCL, SDSF, MVS delivery and installation 
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> ABCs of z/OS System Programming - Volume 2: z/OS implementation and 
daily maintenance, defining subsystems, JES2 and JES3, LPA, LNKLST, 
authorized libraries, catalogs 


> ABCs of z/OS System Programming - Volume 3: Introduction to DFSMS, 
storage management 


> ABCs of z/OS System Programming - Volume 4: Communication Server, 
TCP/IP, and VIAM® 


> ABCs of z/OS System Programming - Volume 5: Base and Parallel Sysplex®, 
system logger, global resource serialization, Z/OS system operations, 
automatic restart management, hardware management console, performance 
management 


> ABCs of z/OS System Programming - Volume 6: RACF®, PKI, LDAP, 
cryptography, Kerberos, and firewall technologies 


> ABCs of z/OS System Programming - Volume 7: Infoprint® Server, Language 
Environment®, and SMP/E 


> ABCs of z/OS System Programming - Volume 8: z/OS problem diagnosis 
> ABCs of z/OS System Programming - Volume 9: z/OS UNIX System Services 


> ABCs of z/OS System Programming - Volume 10: Introduction to 
z/Architecture™, zSeries processor design, zSeries connectivity, LPAR 
concepts, and HCD 


> MQSeries Primer, REDP-0021 
> IBM DB2 Performance Expert for z/OS Version 2, SG24-6867-01 


Other publications 


These publications are also relevant as further information sources: 


Online resources 


These Web sites and URLs are also relevant as further information sources: 
> IBM zSeries Homepage 
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http://www. ibm.com/servers/eserver/zseries 

IBM z/OS Homepage 

http://www. ibm.com/servers/eserver/zseries 

IBM Internet Library for zSeries and z/OS 

http://www. ibm.com/servers/eserver/zseries/bkserv 

IBM z/OS Communications Server Homepage 
http://www. software. ibm.com/network/commserver/support/ 
IBM Terminologies 

http://www. ibm.com/ibm/terminology/ 

Description2 


Sysprog Net, Independent Resource for the z/OS System programmer 


http://www. sysprog.net 


How to get IBM Redbooks 


You can search for, view, or download Redbooks, Redpapers, Hints and Tips, 
draft publications and Additional materials, as well as order hardcopy Redbooks 
or CD-ROMs, at this Web site: 


ibm.com/redbooks 


Help from IBM 


IBM Support and downloads 
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Your glossary term, acronym or 
abbreviation. Term definition. Sort terms: 
highlight rows>Table>Sort>Column1>Sort 
Term1. Term1 definition. 


Term2. Term2 definition. 


Term3. Terms definition. 
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